December 2003 - cypherpunks-legacy

Re: Remailer ideas (Was: Re: Latency vs. Reordering)
by Jonathan Rochkind 17 Dec '03

17 Dec '03

> * Rochkind's stability-from-being-paid and web-of-trust notions I'm not sure I like being credited with the "stability from being paid" notion. I think there _is_ stability from being paid, but I think if the infrastructure depends on it, it's not a good infrastructure. The system should be able to create a stable top-level infrastructure on top of an inherently instable environment, with remailers going up and down, and popping into existence, and dying. It should route around dead remailers, like the internet itself. > Where email is used to transfer messages, the format used should be > a subset of that specified in the SMTP RFCs. Restricting the structure of the headers would simplify the remailer software at little cost to the user. > > The use of alt.x groups to exchange gateway information does not seem > to add anything to this system; in fact it would seem to make it easier > to spoof the system. It _would_ make it easier to spoof the system, but I think it does add several very important things: 1) New remailers can easily announce themselves to the remailernet. [Whether they are to be trusted or not should depend on pgp-signed keys and web of trust, but the newsgroup provides an way to announce yourself to the system, and have that announcment by automatically dealt with by all participating parties] 2) Users (not people operating remailers, people using them) could make use of the newsgroup, to compile a database of remailers, and make long remailer chains. Users could have automated software doing this. [again, taking account of web-of-trust through signatures]. Messages posted to the newsgroup could include information on whether the remailer is free, or whether ecash is charged, and the user's software could automatically take account of this, enclosing ecash certificates in the proper encryption blocks for for-profit remailers. (and reporting costs to user for approval, of course). These are really two facets of the one problem, of allowing a user or remailer who has just arrived on the seen to quickly get a list of remailers, and make use of them, all automatically. That's sort of the super-set problem which encompasses the other two, and whose solution solves the other two. I don't think it's a coincidence that the newsgroup system solves these two problems at the expense of security (the newsgroup makes it easier to spoof). I have a gut feeling that any solution which solves these problems is going to be at the expense of security. But I think these two problems need to be solved if we want to create an easy to use, low-human-maintance, infrastructure in a universe of hundreds of remailers. The fact is, that even remailers exchanging mail _can_ be spoofed, if not quite as easily as the newsgroup idea. It seems to be a premise of cryptographic protocols and schemes, that you've got to assume a worst case and get a system working where even under the worst case, everything works. I think this is a good way to work, and that's why you've got to assume that if it can be spoofed, it will be spoofed. And you've got to build in a web of trust relying on cryptographically secure signatures, instead of relying on false security you get from thinking that it hasn't been spoofed just because it would be a little bit dificult to do so. Once you adopt this frame of mind, the newsgroup method is just as secure as the mail method (both can be spoofed, but you rely on web-of-trust to prevent spoofing from doing any harm), but the newsgroup method solves the two problems I brought up. I agree that it seems a good idea for the SMTP RFCs to be used to exchnage info, and we could post to the alt.remailernet newsgroup with articles that adhere to the SMTP RFCs, even though that isn't exactly what the those RFCs are intended for. Although we almost certainly need some agreed upon standards in addition to the SMTP RFCs, because there is additional information we want to exchange.

1 0

Censorship/protecting children is not on topic...
by Tommy the Tourist 17 Dec '03

17 Dec '03

This debate about protecting children from censorship, et al is great, but arn't we veering off the charter/topic of this mailing list? ------------ To respond to the sender of this message, send mail to remailer(a)soda.berkeley.edu, starting your message with the following 8 lines: :: Response-Key: the-clipper-key ====Encrypted-Sender-Begin==== MI@```%E^&2?(E<U9BPG1]W7L'=&KH_PWY8"RO>+Y2-*'0G?5^"B<Y9[>%&EG M0_U[L1(6_(\$"))OK>(OA8H+I%T@3K;%1ON[7^#@]3[:`$.O0\]*<1^R&ZKY $R7JWF@`` ====Encrypted-Sender-End====

1 0

Remailer ideas
by Hal 17 Dec '03

17 Dec '03

The MIRV idea for messages is not bad, but by itself it does not provide enough cover. If you have a 33K byte message come in and a while later a 21K and a 12K byte message go out, there might not be many other possible messages that could add up to 33K. A more complete solution is to pad all messages to a standard size. If every message which goes into the remailer is the same size, and every message which comes out of the remailer is the same size, and each has no carried-over header or message-body information, then there should be no way of matching up incoming to outgoing message. This was the simple solution in Chaum's original February 1981 CACM paper, which I would strongly suggest that people read. CACM is probably the most widely available of the computer science journals and should be at every university library. Chaum's paper has some interesting aspects that are not often mentioned. He actually proposes two different solutions that differ somewhat. (People should also be aware of his alternative solution to the traffic analysis problem, the "Dining Cryptographers" network. I think Tim may have scanned that in at some point, so it might be on the net. DC nets tend to be high bandwidth and are more suitable for LANs or WANs than email, IMO.) The first solution in Chaum's paper is the "Cascade". In this there is a sequence of "Mixes", what we would call remailers, which are used in a FIXED order by everyone. It's as though everyone first sent their messages to soda, then to portal, then to catalyst, and so on through some specific sequence. Furthermore, these are all sent in a set of batches which stay together as they move through the network. A batch of messages starts at soda, then at a later time that same batch pops out the other end, having been decrypted and shuffled at each step. >From our perspective, this seems like a wasteful way of using the network. By keeping the messages together like this, the whole cascade does no more shuffling than would a single mix. Using the cascade provides no more confusion of messages. But the advantage it does provide comes from the fact that there is no guarantee that the remailers are honest. This is something which is often overlooked by people who make suggestions that remailers should cooperate, should automatically choose the message paths, etc. Chaum uses the cascade so that if even one mailer on the chain is honest and uncorrupted, the whole chain is strong. If you _knew_ you were using a good remailer you wouldn't need a cascade. But by using a cascade you get that much more assurance that you have security. The other reason for using a fixed cascade, I think, has to do with the details of message padding. The problem is that, generally, when you decrypt a message it is not exactly the same size as it was when you started. Particularly with remailer messages, where there may be some encrypted address information along with the message, the output will tend to be smaller than the input. By using a cascade, the messages will all shrink in step as they move along. All of the messages coming in to any mix in the cascade will be the same size, and all the messages going out will be the same size, but the outgoing messages may not be the same size as the incoming ones. It is this size differential which would make it hard to safely combine messages which have gone through different numbers of mixes. Chaum does go on to suggest a solution to this as the second main part of his paper. That part is considerably harder to follow, but the main idea seems to be that the mixes themselves will add padding to the end of the messages so that they stay the same size. Chaum describes this in terms of messages composed of fixed-size blocks, but it would seem that the idea could be generalized to a remailer which added random padding to bring the output message up to the standard size. I can't see any security leaks in this generalization. One interesting idea Chaum suggests is that after the remailer decrypts the messages in its batch, it does not simply send each one to the next address, but rather broadcasts them (perhaps to all of the other remailers). Those remailers try decrypting all of the incoming messages and only those messages for which the decryption succeeds will be sent on. Again, I'd suggest people interested in reamailers read this paper. I believe there were some follow-ups in the Crypto 89 proceedings, but my library is missing that volume so I haven't seen them. Hal

1 0

No Subject
by Blanc Weber 17 Dec '03

17 Dec '03

who cypherpunks

1 0

(fwd) Latest Cyberwire Dispatch
by paul＠hawksbill.sprintmrn.com 17 Dec '03

17 Dec '03

I couldn't recall this already being posted to the list, so apologies if you've already seen it. As the syaing goes, "Be afraid. Be very afraid." - paul Forwarded message: > From: mech(a)eff.org (Stanton McCandlish) > Newsgroups: comp.org.eff.talk > Subject: Latest Cyberwire Dispatch (fwd) > Date: 5 Aug 1994 11:18:07 -0500 > Organization: UTexas Mail-to-News Gateway > Lines: 186 > Sender: nobody(a)cs.utexas.edu > Distribution: inet > Message-ID: <199408051618.MAA21205(a)eff.org> > NNTP-Posting-Host: news.cs.utexas.edu > > [This is just an informational forward, and is not an EFF statement.] > > > ****** begin fwd ******* > > CyberWire Dispatch // Copyright (c) 1994 // > > Jacking in from the "The Good, the Bad and the Ugly" Port: > > Washington, DC -- For months now a kind of high stakes privacy poker has > been played out here behind the closed doors of congressional subcommittees > as the FBI, telephone industry executives, congressional staffers and civil > libertarians have played a kind of five card draw with the privacy of all > your future telephone calls, faxes and electronic mail. > > The betting's all but over now; Congress has "called" the hand and laid > its cards on the table: A soon to be introduced bill that will mandate > --forever -- that all the nation's telephone networks be designed to give > the FBI easy wiretap access. The bill's sponsors, Senator Patrick Leahy > (D-Vt.) and Rep. Don Edwards (D- Cal.), have fought through a numbing array > of options, opinions and (FBI) obfuscation in order feel comfortable enough > to sign their names to a bill that, just years ago, was laughed off Capitol > Hill because it was severely flawed. > > My how time changes things. > > It's been two years since the FBI first introduced what amounted to an > "Easy Wiretap America" bill. Now we have a new President, a new FBI > director and suddenly, a new bill that requires the nation's > telecommunications providers to reengineer their facilities so the FBI can > do wiretaps easier. > > The Leahy and Edwards staffs have dumped hundreds of hours of "sweat > equity" into this bill, which could be introduced as early as today > (Friday) but certainly before next Tuesday. > > Leahy and Edwards have never been known to tape "kick me" signs on the back > of American privacy rights. The bill that's been hammered out here -- and > that phrase isn't used lightly -- by Leahy and Edwards is a damn sight > better than the FBI's laughable attempts at drafting legislation. In fact, > it was Leahy and Edwards that stepped into the breach to thwart those early > FBI proposals from being passed "as is." > > An earlier version of this bill, which, among other things, gave the > Justice Department the right to shut down any telephone company's network, > regardless of size, if they didn't comply with the wiretap statute, was set > to be introduced by Sen. Joseph Biden (D-Del.), with heavy support from > others in congress. That bill, if introduced, would have passed, > congressional sources have said. > > But the Leahy and Edwards tag team effort took Sen. Biden off the scent. > So, we get a more palatable bill. Call it the "cod liver oil act" of 1994. > It tastes horrible, but it's necessary, considering the earlier > alternatives. Without this Leahy/Edwards bill our privacy rights would > have really been fucked over. At least now we get kissed. (Sorry, no > tongues.) > > Still Got The Power > ==================== > > A draft copy of the latest bill, obtained by Dispatch, shows that the > Justice Department and FBI still have the tools to intimidate and harass > the future development of the nation's telecommunications infrastructure. > > The bill, as it stands, does keep Justice and law enforcement from > mandating any "specific design of features or system configurations to be > adopted." But the requirements to build wiretap capability into all public > telecommunications carrier systems is steadfast. This means that while the > FBI can't expressly tell a company "how to get there," it can definitely > say, "just get there." > > Never again, under the provisions of this bill, will a telecommunications > provider be able to develop a service or technology without first and > foremost asking the question: How can I design this so that it pops off > the assembly line wiretap ready? > > Read it again. The key word there: Never. > > There is an "out" however, and it comes thanks to Leahy. If a new > technology doesn't fit with the mandate, that is, if you can't make that > new hand held satellite phone wiretap ready and you've made every > "reasonable effort" to make it so, it can still be sold. How? > > "The court can enforce the (wiretap) requirement of this act only if > compliance with the act is 'reasonably achievable' through the application > of 'available technology,'" said Jeff Ward, director of governmental affair > for the Nynex telephone company. > > Ward -- who says the bill has been an "albatross" around his neck for 2 > years -- has focused his efforts during this 2 year time frame, on ensuring > that such "reasonably achievable" provisions allow telephone industry and > equipment makers to be "good corporate citizens." That is, these > companies are required to consider [wiretap] design factors, but if after > "due consideration, we can't do it, we've got to be able to proceed." > > This effort is supported by the bill; however, it is a court of law that > decides what is "reasonable" or not. Such litigation, brought by Justice > no doubt, could tie up a new technology for years while the case is > decided, thus giving Justice and the FBI a kind of de facto control over > the development of new technologies. > > Make That Check Out To... > ========================= > > Then there's cost. The FBI insists that the cost to industry to retrofit > all their networks will be only $500 million. But that's a bullshit figure > and everyone from FBI Director Louis Freeh to the newest line programmer at > AT&T knows it. > > In fact, so many lines of code will have to be written and maintained to > comply with these wiretap mandates that one Internet pioneer, Dave Farber, > has called the FBI proposal "the programmers full employment act." > > Provisions in the bill make it basically a blank check for the FBI. Within > the first 4 years, there is $500 million approved to be spent on > "upgrading" all the nation's telephone systems to provide law enforcement > with easy wiretap access. There are provisions in the bill that require > the government to repay all costs of installing wiretap software throughout > all networks forever, with no cap. What's not clear, however, is what > happens when FBI demands for wiretap capability exceed the $500 million > mark (and it will) during those first 4 years. > > Maybe we'll get some answers when this bill (in whatever language is > finally passed) is discussed at joint hearings to be held by Leahy and > Edwards on it August 11th. > > Take It or Take It > =================== > > Take it or take it. Those are your only choices here. This bill is a slam > dunk for passage. But you didn't lose everything. > > All electronic systems will be exempt from complying with the bill's > mandates. But hold on before you cheer... > > This simply means that the FBI can't tap your Email from, say, America > Online's computers; rather, they can do what they've always been allowed > to do: Snag it off the telephone company's central switch. But at least > we don't have the Internet being hung with "FBI: Tap In Here" signs. > > Transactional data, Dispatch has been told, will get some beefed up > protection. Just how this language shakes out remains to be seen, however. > > > Yeah, but Can They Count? > ========================= > > At the very end of the draft we obtained, the FBI is given a curious > additional reporting requirement under its annual wiretap reports. The > addition, in our draft copy, says the Bureau must quantify "the number of > interceptions encountering electronically encrypted communications, > specifying the number of such interceptions that could not be decrypted." > > Throughout the history of this bill and the now ignominious Clipper Chip > proposal, the FBI has touted the fact that it's investigations are > continually stymied by encryption technologies. Small problem: The Bureau > refuses to provide any kind of documentation to back up those claims. > > At first blush, then, this extra requirement finally means the G- men will > have to give us some concrete numbers. All well and good... *if* that's > what this requirement actually is used for. > > There's potentially a much darker use for these stats... yes, I see all you > Crypto-rebels nodding your anxious heads. You see, such a formal gathering > of statistics could be used by the Bureau or... say, the National Security > Agency, to "prove" that private encryption schemes are just too great a > threat to "catching bad guys." > > Citing these newly gathered statistics the White House could, one day, > order the banning of private encryption methods. Far fetched you say? > > Yeah, it's far-fetched... something on the order of, oh, say a bill that > mandates telephone companies give the FBI easy access to all conversations > from now until forever. > > Meeks out... > > ******* end ******** > > > -- > <A HREF="http://www.eff.org/~mech/mech.html"> Stanton McCandlish > </A><HR><A HREF="mailto:mech@eff.org"> mech(a)eff.org > </A><P><A HREF="http://www.eff.org/"> Electronic Frontier Fndtn. > </A><P> Online Activist > >

1 0

Re: Voluntary Governments?
by Jeff Barber 17 Dec '03

17 Dec '03

solman(a)MIT.EDU writes: > That's because neither is. A and B are just two folks who might want to > communicate with each other. Party A may have a "law" that prohibits any > form of fraud and fines violators an amount set by some "politician". > The law that A chooses might be quite restrictive (like many > of the truth in advertising laws we have in the physical realm.) B is just > some random person who wants to communicate with A. Maybe he has something > he wants to sell to A. Suppose that B is not adhering to the laws that A > has chosen. When he attempts communication, A's agents will inform B's > agents that A wouldn't feel safe under B's laws. One of three things will > happen: > 1) B really would like to do business with A so he temporarilly accepts A's > laws. This probably involves giving the following process: I think I now understand what it is you're saying. But the protocol you describe is merely that of a trusted escrow agent, which is not a government. Governments can sometimes act in that capacity (for example, if you default on your mortgage, the govt. will hand over your house to the mortgage holder). One difference between the government and other trusted "adjudicators" is that -- and this goes back to an earlier idea in this thread -- the government has the force of arms to back up its decisions. (If you don't make your monthly payment, the bank goes to the adjudicator [the govt.] who turns over the property to the bank and evicts you. If you refuse to leave, the govt. sends men with guns to your house to force you out.) Any other agent would need to have some economic or other pressure it could apply to you to compel you to follow the "rules" you agreed to. Without the threat of force, though, this can hardly be called a government. You're simply taking an existing concept -- that of a trusted adjudicator, which need have no connection with a government -- and calling it "government". This doesn't make it so. I am reminded of this [Lewis Carroll?] quote Steve Bellovin posted several months ago: ``When *I* use a word,'' Humpty Dumpy said, in rather a scornful tone, ``it means just what I choose it to mean---neither more nor less.'' > > Please describe how a "voluntary" > > government would prevent "aliens" from conducting their own economic > > transactions completely outside this system. > > It wouldn't. But a cyberspatial government could limit the contact > that ailiens have with its citizenry, thus denying the aliens access to > the information and resources of the government's citizenry. In tyranical > cases, the government could even prevent aliens from explaining to the > citizens just how much money they are losing by remaining in the government. This whole scheme rests on the willingness of relatively large groups to put themselves under the control and protection of this cyberspace "government" in the first place. I still don't see what the motivation will be. What advantage to me will there be in allying myself with this government, when I could instead choose a particular trusted arbitrator or adjudicator or escrow agent on a case-by-case basis when and if it's needed? How will one of these governments ever acquire the critical mass necessary to make anyone care what their rules are? And the question of motivation is central to your conclusion, which was: > > > Without extreme cultural upheaval, it is highly probable that voluntary > > > economic coercion alone will be sufficient to allow big government > > > to move from the physical realm into cyberspace. -- Jeff

2 1

Re: URGENT: Please Tell Congress to Allow Encryption Export
by Jim Dixon 17 Dec '03

17 Dec '03

In message <9408050823.ZM6861(a)simple.sydney.sgi.com> Ian Farquhar writes: > On Aug 4, 10:08am, Chris Corpuz wrote: > > The House and Senate Intelligence Committees, the only watchdogs for > > the NSA, tend to follow the agency's wishes when they wave the magic > > "national security" wand. > > Reading this, I was reminded that I have rarely seen any mention on the net > as to one of the reasons why the "national security" wand is so effective with > many politicians. > > Imagine this: you're a politician. If you're a US politician in particular > you will be correctly told that you are, by virtue of your position, a target > for a lot of "extremeist" groups and terrorism. [etc] This has little to do with being a politician and even less with being a US politician. People at all levels everywhere at all times are willing to pay for what they perceive as additional security. Look at the world around you. Just before the USSR collapsed, they were well on their way towards building a world class navy, to counter the "US threat". This was a huge investment. Singapore is armed to the teeth, what the hell, most of Southeast Asia is armed to the teeth. What do the Chinese need nuclear missiles for? At a more prosaic level, people everywhere splash out on life insurance policies. The insurance salesman's patter is much the same as the generals' line when talking to the politicians in Washington. Everyone everywhere will pay for what they perceive as security. -- Jim Dixon

1 0

Latency vs. Reordering
by hughes＠ah.com 17 Dec '03

17 Dec '03

This horse isn't dead yet. The distinction between latency and reordering is if primary importance to the cryptanalysis of a remailer network. To repeat yet again: reordering provides security and latency is a by-product of reordering. I assert that anyone who's given a modicum of thought about how to cryptanalyze a remailer network understands this distinction well. I also assert that those who haven't thought about cryptanalysis don't understand the distinction, even if they do believe in it by authority. One of the oldest maxims in the book is "Don't design ciphers until you've tried to break some." A remailer network is intended to be a cryptographic object, a new kind of cipher. I assert that if you don't understand the distinction between reordering and latency, you've not thought enough about the cryptanalysis of remailers and shouldn't be designing them. Therefore, in the future, from here on out, I will label the promoters of latency as "sellers of snake oil." It's the same fallacy as creating a new cipher by putting lots of complicated operations inside it without understanding where the security comes from. Eric

1 0

Clipper in the Commics
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Well, I guess this is about as mainstream as the issue can get. In today's paper, the comic strip "On the Fast Track" is about the clipper chip. It suggests that we need a way to spy on government in return (other than by bribery). To say that I was surprised to see a clipper statement in the 'toons would be an understatement. Looks like our campaign to inform the public is paying off. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkKPYVVkk3dax7hlAQEg9AP5AXe5mr++9Af3QCcyozIKqKqp5FXadKqG Eaj+2An+loxXafaqNVwuKoZJMemA68yRYKguIZKjk6kQPhw3zp5D1h6Ynj3OoUvI AhPHHnDBiA+ehz5FSZfQESdRJtjM+6qQ/vcbgnSBeFvEEYi4531Q9t36pQJcWB8X n2Jlr6U3jjE= =BVHe -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

email packet length size
by hughes＠ah.com 17 Dec '03

17 Dec '03

Message length quantization is necessary for security in a remailer network. Right now there's not enough traffic through the remailers to warrant more than one such quantized length. What length should that be? This information can be readily calculated from the length distribution of the current messages passing through the remailers. If only one or two remailers would instrument their devices in order to record just lengths, that would provide the necessary data. Any volunteers? My complete guess is that it's going to be around 4-5 KB. Eric

1 0