December 2003 - cypherpunks-legacy

Mike Godwin Re: Is there a lawyer in the house?
by John Gilmore 17 Dec '03

17 Dec '03

From: Mike Godwin <mnemonic(a)well.com> Subject: Re: [Black Unicorn: Re: Is there a lawyer in the house?] Date: Mon, 11 Dec 1995 13:27:34 -0800 (PST) > The question is whether the government can legally compel production > of your encryption key(s) if you give them to another person, such as > an escrow agent of your choice, your lawyer, your wife, your bank, > your web site provider, or whoever. Compelling the key from the person you gave it to is easy. (That is, the answer there is yes, assuming no independent claim of non-Fifth Amendment-derived privilege.) Whether you have given it to another person does not automatically make it easier to compel the key from you. But under certain circumstances (and in certain jurisdictions) it might -- such as if, for example, you were relying on a "last link" rule to bar your disclosure of the key. If you were arguing that the disclosure of the key would be a "last link" in a chain of inculpatory causation, and it could be shown independently that you had already disclosed the key to someone else, thereby proving that you possessed the key at one time, your having done so might undermine your "last link" argument. Feel free to forward this. --Mike

1 0

Re[2]: Timing Cryptanalysis Attack
by Martin Diehl 17 Dec '03

17 Dec '03

OTOH, maybe we _should_ try for constant computation time and then try for *random* delay time. Remember that _we_ will spend a lot of real time arguing whether the *random* delay is really _random_ Martin G. Diehl _______________________ Reply Separator __________________________ Subject: Re: Timing Cryptanalysis Attack Author: Nathaniel Borenstein <nsb+limbo(a)nsb.fv.com> at Internet-usa Date: 12/11/95 2:41 PM Hey, don't go for constant time, that's too hard to get perfect. Add a *random* delay. This particular crypto-flaw is pretty easy to fix. (See, I'm not *always* arguing the downside of cryptography!) It is worth noting, however, the extent to which "secure" cryptographic protocols keep needing to get fixed one last time.... -- Nathaniel -------- Nathaniel Borenstein <nsb(a)fv.com> | (Tense Hot Alien In Barn) Chief Scientist, First Virtual Holdings | VIRTUAL YELLOW RIBBON: FAQ & PGP key: nsb+faq(a)nsb.fv.com | http://www.netresponse.com/zldf

1 0

Re: Timing Cryptanalysis Attack
by Peter Monta 17 Dec '03

17 Dec '03

Kocher says this about padding to constant time: > ... If a timer is used to delay returning results until a pre-specified > time, attackers may be able to monitor other aspects of the system > performance to determine when the cryptographic computation completes. Perhaps, but an attack would be much more difficult if the monitoring must be done outside the host doing the computation (viewing a router from the outside, say, as Eric Young alludes to), since the scope for covert channels is much reduced. Peter Monta

2 1

Re: Timing Attacks
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> From: "Rev. Ben" <samman-ben(a)CS.YALE.EDU> > > I'm not so sure I see the great usefulness of this attack. > > I've taken a cursory glance at Mr. Kocher's paper on-line and what it > comes down to essentially, if I undestand it correctly, is that you need > to be as sure of the timing as you can be. > > Now, on a distributed system, you can't measure those timings, because > any latency could come from the originating computer, the links in the > middle or any combination of them. But, what if one of the computers is connected on a "hostile" lan. For example - your typical student PC running in a grad-student office or on the network in the dorms. Sniffing packets from it shouldn't be too hard (yes, good ethernet concentrators make it harder - but not impossible). These packets will give you the necessary timing information. > Also precise timings can be limited by fluctuating load averages amongst > other things in a time-sharing computing environment. While this might > work in a lab, with the current advances in computing speed, the > differences between a fast and a slow calculation can easily be opaqued > by network lag. > > Am I missing something, or does this attack only work in a lab? What if that is a PC running Windoze or single-user Linux? Then there aren't likely to be fluctuating load averages. The advesary is close to the one end, and away you go...... Of course, targeting a server is much more pratical in terms of what you may gain access to. Several congested network hops will generate lots of delays, BUT what about the 4:00am hit from the dialup terminal servers that happen to be on the same ethernet as the secure server. This would be a normal situation for many ISPs. All of that said - I think that this is more pratical in the "lab" than on the net. But, it is a very clever approach to the problem of cracking a crypto system. It serves us all a good example that we need to leave NO stone unturned when examining a system. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Re: e-mail forwarding, for-pay remailers
by Greg Broiles 17 Dec '03

17 Dec '03

E. Allen Smith writes (quoting me): >>netbox.com ( http://www.netbox.com ) provides web pages and E-mail storage >>or forwarding for people; they let you sign up for a trial month for free. >>They ask for name/address/phone (which could easily be a Mailboxes Etc >>address and a voicemail from Mailboxes Etc or whatever) and accept payment >>by check or credit card. >-------------------- > There's one problem with this in regards to the "no necessary >connection," and that 's the governmental requirement for mail forwarding. >MBE and any legal other one will want to see at least two forms of ID >including one photo, and have a form that they fill out using that and >send to the local post office. Anyone have a way around this problem? I spent last summer in San Diego - it took me a couple of weeks to find a place to stay. The first day I was in town I went to an MBE and signed up for a box - showed them my Oregon ID and said "I don't have a local phone # or address because I've been in town only 12 hours. That's what I need you folks for." They cheerfully wrote down the information from the front of my drivers' license (which is 5 years out of date) and gave me a box. They also asked if there would be anyone else who'd be getting mail at my box - I could have specified a business or some roommates. They didn't need to see ID for those - so you're free to name some real or imagined roommates/friends, who might coincidentally sign up for E-mail forwarding. (Or you can just say that "Greg is my real name but John Doe is my trade name, I get mail under that name too." "Trade names" aren't so unusual for people in show business or authors or, I read recently, bill collectors. Apparently they don't want people calling them up at home hassling them. Imagine that. :) ) The folks at the San Diego MBE have been cheerfully forwarding my paper mail back here to Oregon as long as I want to keep paying the postage (plus some sum that they're adding on that's not big enough to pay attention to). It's not the kind of untraceability I'd rely on vis-a-vis a TLA, but it ought to be good enough to keep your posts to alt.sex.forbidden from showing up on your boss' desk via DejaNews, or to allow you to go ahead and piss off part-time fascists who don't have the energy to chase down the paper trail. -- "The anchored mind screwed into me by the psycho- Greg Broiles lubricious thrust of heaven is the one that thinks every temptation, every desire, every inhibition." greg(a)goldenbear.com -- Antonin Artaud gbroiles(a)darkwing.uoregon.edu

1 0

Re: Attacking Clipper with timing info?
by Herb Sutter 17 Dec '03

17 Dec '03

At 20:10 12.13.1995 CST, Loren James Rittle wrote: >If it could be shown that Clipper chips require a fixed amount >of time/current to encode/decode traffic, then we could conclude >one of the following: > >(B1) The NSA knew about the issue and compensated for it. >(B2) The NSA didn't know about the issue and got lucky. > >I discount B2 as a valid option. Actually, if the answer was B1, >my respect for the NSA would creep up a notch. :-) Remember those carefully-chosen S-box numbers for DES and how, years later, how they just happened to turn out to be optimal for defending against the newly-discovered (in non-military circles) technique of differential cryptanalysis... :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Herb Sutter (herbs(a)connobj.com) Connected Object Solutions 2228 Urwin - Suite 102 voice 416-618-0184 http://www.connobj.com/ Oakville ON Canada L6L 2T2 fax 905-847-6019

1 0

Timing attack against RSA
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here is how I gather the timing attack against RSA decryption would work. This is the chosen-ciphertext attack of Paul Kocher's. You know n, the public modulus; suppose it is 512 bits. You want to know p and q, its prime factors. You know the details of the server's implementation of RSA. The server will do a decryption of the RSA message you send it, and give you some reply shortly after it is finished. You are going to send it bogus messages. Normally, most random messages will encrypt under RSA to numbers of about 512 bits, but you will send it ciphertext which is about 256 bits long. You are going to try to figure out the value of p. The server's algorithm is to take the ciphertext c, and first do: cp = c mod p cq = c mod q It will then do two modular exponentiations, mod p and mod q, and do a few more calculations, then return some result to you. The attack is to try to choose c to be about the same size as p, with the assumption being that if c is a bit less than p then c mod p will be fast since it doesn't have to do anything, while if c is somewhat larger than p then c mod p will be a little slower, since it will have to at least subtract p from c. Paul Kocher has measured this timing difference as 17 microseconds on one particular implementation. This is not going to be an easy time difference to measure. In addition to doing the c mod p step, the algorithm also does all those other things: the c mod q, the two RSA calculations, as well as whatever overhead is involved in the server's operation and the communication link. The variations due to the RSA calculations themselves will have a standard deviation of about 250 microseconds, based on Paul's numbers (higher than his reported value because two exponentiations are done, plus some other work). So this is a minimum amount of "noise" we must try to see through even if everything else is instantaneous. This might be the situation in the case of a hardwware token which is doing RSA decryptions with a secret key. The first step will be to try to determine the length of p. For this we will send in c values which are around 256 bits long. We might start with some 250 bit values and some 260 bit values, hoping that p is in that range. We do a whole lot of these, and we take the average time for them. If p is between 250 and 260 bits long, then the 260 bit values should take at least 17 microseconds more time to calculate on the average than the 250 bit values. One interesting question is how many samples we would have to take in order to detect this difference. One way to consider it is to ask, given that the samples have a standard deviation of about 250 microseconds, how many samples do we have to take to reliably estimate the mean within an accuracy of about 10 microseconds, or 1/25 of a standard deviation? According to my limited knowledge of statistics, if we want to be right about 90% or 95% of the time, we need to have sqrt(number-of-samples) * 1/25 be > 3, or number-of-samples should be about 5000. (Take this with a large grain of salt!) So we will have to do some thousands of samples in order to average out the noise and get our mean this accurate, with good confidence. Once we have done these tests, we have determined that p is between our two values. Now we can sub-divide the interval and poll with values which are, say, 255 bits long. Again, we would have to do enough polls to determine the true mean time to within about 10 microseconds. After we repeat this three or four times, we will know the bit length of p; in effect, we know its first bit. Now we can continue the divide and bracket procedure. Each time, we must poll many times with c values whose most significant bits are halfway between the two bracketing values which we know contain p. Each such sequence of about 5000 polls yields us one more bit of p. We repeat this about 250 times, and we will have p, from which we can derive q, and we have broken the RSA key. So, taking the estimate above of 5000 or so samples to get a bit of p, we will have to do about a million tests total to find p. (BTW, in Paul's implementation it took about 1/3 second to do a decryption, so you're looking at about 100 days of solid work to do the job.) This algorithm has some self-correcting features but it is not completely so. Suppose p's first bits are actually 1011. We have determined that it is between 1000 and 1100, and we want the 3rd bit. We poll with values which start with 1010, and (since with 90% accuracy we are wrong 10% of the time) we mistakenly conclude that the mean is the higher value, hence that p is less than 1010 and must start as 100X. We continue the procedure, and we will find that our new middle values are consistently less than p, so we gradually work out our estimate as 10011111... Eventually this train of 1's might persuade us that we may have made a mistake back there, so we would go back and poll again to try to verify our earlier results. (Of course, if another mistake happens during the 1's that will confuse us further...) Doing the attack across a network will be much more difficult because there will be a lot more variation in the turnaround time. This will have the effect of increasing the standard deviation far above a quarter millisecond, up by probably at least an order of magnitude if not two or more. Now we have to estimate a mean to within not 1/25, but maybe 1/1000 of a standard deviation, or worse. This would increase the total number of samples necessary from a million up to the level of billions or trillions. One final note: two cases to which we might want to apply this would be Netscape's SSL as implemented by its secure servers, and DigiCash's bank software. (I know Lucky said that DigiCash is immune to this attack, but maybe we would want to test it to see.) In either case, since we are sending a bogus 256 bit value, the data which decrypts will not be valid. In the case of SSL we will probably get an error packet or maybe a broken connection to tell us when it has finished the decryption. In the case of DigiCash, it does not need to do anything with the value it signs other than return it, so we will probably get a return packet. However, it is not valid cash. In order to convince DigiCash to send us this packet, it has to have deducted something from our account, at least a penny. If it takes a billion connections to do the attack (which I think is an underestimate, corresponding to about a 10 millisecond standard deviation on the timing values), that will cost 10 million dollars. So you better have pretty deep pockets to think about mounting this attack in that case. For SSL, misses don't cost you anything, so maybe it would be worth trying, if you have a good, low-latency connection and a server with a light load. The full attack would take too long but just determining the length of p would be quite a coup. Actually of course you would have to do some more research before mounting this attack; specifically, you'd want to know more about the timing of the software so you could estimate the costs of the mod p operation you are trying to catch. If the number ends up being much less than 17 microseconds the attack gets that much harder. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBMM961RnMLJtOy9MBAQFBgAH/WQTMSvRySqNXpfnI4kNXUKQPAleV4NUL ciaDg9VrY8OOJ0cYO8aZ+RnGn+BKp7WFbIkIKFDO3mSE/o9Be2uI7w== =ijGI -----END PGP SIGNATURE-----

1 0

Re: e-Cash: CAFE vs. Mondex
by James A. Donald 17 Dec '03

17 Dec '03

At 11:34 AM 12/12/95 +0100, Matthias Schunter wrote: > We will soon publish our full protocol and architecture specifications. > A short 50-page summary is already available (PostScript). While I appreciate all the good work you guys are doing, it is often said that when people wish to nominally make things public without the risk of too many people paying attention, they make a postscript file, and when they really want the world to know, they make a bunch of html files. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

3rd party beneficiaries and certificates
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Dear cypherpunks: Professor Froomkin posted the following interesting questions to cyberia-L, and gave me permission to repost them here. Please direct any private replies to him <froomkin(a)law.miami.edu>. My apologies to those of you who hang out in both dens for having to see the same message twice. JMR [Forwarded message follows] I've been trying to work something out. (I've written these questions in the form of an exam because it's that time of year. In fact, I'm struggling with these in a paper I'm working on.) Carol runs a certificate authority (CA). She sells a certificate to Alice binding Alice's public key to her name and email address. In version (A) of the contract Carol posts the certificate on her web site. In version (B) of the contract Alice gets a floppy disk with the certificate. The certificate is in error (due to Alice's fraudulent or negligent misrepresentation to Carol). Bob relies on it to his detriment in a transaction with Alice. Assume Bob can show but for causation of his loss. Bob now wishes to sue Carol for negligent misrepresentation. He has, I think, three possible theories. 1) UCC. This turns on whether a certificate is a "good" or a "service". {Assume the answer is "service" for the rest of this hypo} 2) Contract. Bob has to show that he's an intended beneficiary under the restatement 2d test. This seems to be almost a theological question. Is the purpose of the certificate to give Alice a tool to induce Bob to transact, or to give Bob a benefit without which he will not transact? 3 )Tort of negligent misrepresentation. To make this especially exciting, let's assume all the action is in NY where the shadow of Cardozo still looms. NY retains a strong privity rule: You can only recover for a negligent misrepresentation if you are in privity of contract with the speaker. Question 1: If Bob is an intended beneficiary, is he in privity with Carol? (I think the answer is "yes"). Question 2: Are Bob's rights, or his status as an intended beneficiary, affected by whether the contract is form A or form B above? The classic cases, like Ultramares have the accountant's report spread around by the client. Suppose the accountant in Ultramares instead publishes the report on the Web -- what result? OK, now we change the facts. We're not in NY anymore, we are in a state that follows the restatement 2d rule in sec. 552. Question 3: Is Bob within the class of forseeable users entitled to recover for the tort of negligent misrepresentation as these terms are used in the restatement? Question 4: Is the certificate a good or a service? (I say it's a service, mostly, unless it makes no representations at all about its quality.) Extra credit: Look up http://www.verisign.com/netscape/legal.html and find the disclaimers in THE BIG TYPE. Do you know of any court that would enforce these? On a "good"? On a "service" provider? A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here. [End forwarded message] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMM+jfW1lp8bpvW01AQFe7QP/dlWbaICoo7lgtTZVsZvd4dvKx3LawfU9 FH8e78Tpo5ICgfKwBNNj6MlBgG7sxAu2LTqMHTTHkcuHksdNTZImJlnNs64phnK0 zBF7IqcT1BOBijWiFWdni+i62NGzppj0BKnyebmFivUbwmi4QGN3gLMxkvD94eWI TU7/+tFB/iI= =8JOv -----END PGP SIGNATURE-----

1 0

Re: Jim Quinn interview of James Norman (edited)
by Ed Carp (ecarp＠netcom.com) 17 Dec '03

17 Dec '03

> To: ecarp(a)netcom.com > Cc: cypherpunks(a)toad.com > Subject: Re: Jim Quinn interview of James Norman (edited) > Reply-to: perry(a)piermont.com > Date: Tue, 12 Dec 1995 14:53:14 -0500 > From: "Perry E. Metzger" <perry(a)piermont.com> > > According to the headers, you, Mr. Carp, forwarded this to > Cypherpunks, when it was obviously available to those that wanted to > read it on a variety of other mailing lists. > > Please don't continue doing this. > > Jon Roland writes: > > The following is a Radio Interview between James Norman, > > formerly Senior Editor of Forbes Magazine and now with Media > > Bypass Magazine and Jim Quinn, DJ of WRRK 96.9 FM in Pittsburgh. > > In this interview from December 7th, they discuss issues of > > national importance and STUNNING IMPACT. Essentially they give > > out the reason for Vincent Foster's Death, and the fact that > > the "resignations" of the Congresspersons are NOT for policy > > reasons but because they have been caught with millions in > > corrupt funds in Swiss Banks. Read this to learn what the > > "mainstream media" doesn't ever tell you... Unfortunately, even I sometimes hit the wrong button on my mailer.

1 0