- cypherpunks-legacy - lists.cpunks.org

Re: Time-based cryptanalysis: How to defeat it?
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:56 PM 12/10/95 -0800, anonymous-remailer wrote: >Assuming Alice is decrypting a secret message sent to her >by Bob (on her very slow C64 ;), and Mallet is watching >with a stopwatch in hand, hoping to determine Alice's secret >key... The modern equivalent of that very slow C64 is the smartcard/ electronic wallet. Sounds like we'll have to implement them very carefully.... >It would be good to place inside the decryption routines >a timer (WELL PLACED!) that waits a random-number of cycles >(based on key-strokes, mouse position, etc.) to defeat this >type of cryptanalysis? The most interesting detail in the paper, to me, was: PK> Computing optional Ri+1 calculations regardless of whether the exponent PK> bit is set does not work and can actually make the attack easier; PK> the computations still diverge but attackers no longer have to identify PK> the lack of a correlation for adjacent zero exponent bits. My immediate reaction to the description of the timing attack on Diffie-Hellman had, of course, been to do precisely that :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

2 1

Rogue root domain reconfiguration [CNN]
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > ADMINISTRATION SAYS INTERNET RECONFIGURATION WAS ROGUE TEST > > graphic February 4, 1998 > Web posted at: 9:29 p.m. EST (0229 GMT) > > WASHINGTON (AP) -- The Clinton administration said Wednesday it was > confident a researcher in California won't repeat his rogue > reconfiguration of the Internet -- a test that few users noticed but > that raised concerns about how the worldwide network is run. > > Jon Postel, who runs the Internet Assigned Numbers Authority at the > University of Southern California under a Defense Department > contract, last week redirected half the Internet's 12 > directory-information computers to his own system. > > Normally, those so-called "root servers" help users find addresses > on the Internet by pulling data from Network Solutions Inc., a > private company in northern Virginia that operates under a federal > government contract.

1 0

Potential defense against timing attack on Diffie-Hellman
by Bill Stewart 17 Dec '03

17 Dec '03

The timing attack on Diffie-Hellman depends on assumptions about what multiplications are being made, and in what order. But you don't need to do them in order. The standard approach to calculating Y**x mod m is to calculate Y[1] = Y, Y[2] = Y**2, Y[3] = Y**4, .... Y[logx] = Y**(logx), and while you're doing this keep a running total r[i], where r[i] = (bit[x,i]) ? (r[i-1]*Y[i]) : r[i-1] all arithmetic modulo m (and all indices possibly off by one :-) This may be a bit memory-intensive for a smartcard, but there's no need to calculate these partial products in order; precompute the Y[i], pick a random permutation of 1..(logx), and compute the partial products in that order. This still leaks the number of 0 and 1 bits in x, but it doesn't say what they are. You probably still should multiply r[i-1]*Y[i] whether you're going to need it or not; I don't think the method hides enough information otherwise, but that needs more analysis. Cost - mostly administrative, plus the memory, since keeping track of permutations of small integers is cheap relative to bignum multiplication and modulo calculations. You also need a random number generator of some sort; LFSRs seem to be an easy way to do permutations on the fly, so seed them with something decent. How effective is it? I'm not sure - I'd need to do a lot more analysis than I've done so far, and the long version of Paul's paper would help :-) But at first glance it looks like it makes it much harder; no two calculations are in the same order, so feeding the system related Y = g**y mod m each time doesn't tell you much. As a further annoyance to the listener, split the permutation at random into two or three pieces, compute their products separately, and then multiply those partial products together. (Don't try this at home without analyzing whether it may leak more information than it conceals...) At very minimum, take two numbers you've got lying around and multiply them every once in a while :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

FT.com Registration
by Site.Feedback＠FT.com 17 Dec '03

17 Dec '03

This mail is to confirm your registration with FT.com, the Financial Times' web site. Please keep this note of your username and password in a safe place to look up should you forget them. If you have any problems getting into and around the site at any time please first try our help pages at http://www.ft.com/about/index.htm . These are open pages which don't require you to log in. If after reading them you still have difficulties, then contact us by email at site.feedback(a)ft.com . User name - hackworth Password - writecode The Internet Team @ FT.com.

1 0

Re: NIST GAK meeting writeup, LONG part 3 of 3
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Pat Farrell writes in his report on thi NIST GAK meeting: >>Geoff said that they may want legislation support for >>protecting against illegal release of keys, failure to release, etc. Jim Bell Responds: > Pardon me, but since this "key escrow" system was always claimed > to be "voluntary," then how can there be any kind of legal penalties > associated with "failure to release" those keys? well, since the subject at hand is Escrow Agent Criteria, "Geoff" is probably talking about the failure of an escrow agent to release a key upon production of "lawful authorization" .... andrew

1 0

Re: NIST GAK meeting writeup, LONG part 3 of 3
by jim bell 17 Dec '03

17 Dec '03

At 11:04 AM 12/10/95 -0800, you wrote: > >NIST Key Export meeting, December 5, 1995 Long version >Part 3 of 3. > >This covers the notes on agent criteria, and the >industry presentations. > [stuff deleted] > >Geoff said that they may want legislation support for >protecting against illegal release of keys, failure to release, etc. Pardon me, but since this "key escrow" system was always claimed to be "voluntary," then how can there be any kind of legal penalties associated with "failure to release" those keys? Which raises another question: Let's suppose I owned a product based on CKE, and I went to the escrow agent and said, "This escrow is voluntary, right? If so, erase my key in your possession." Not that I'd trust them to do so, but how "voluntary" can a system be if people can't volunteer out of it?

1 0

Re: Why can't I get PGP from MIT
by jis＠mit.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >I believe I had a problem when I wanted to get PGP coming from >internexus.net (New Jersey). I just e-mailed them about it and I think >they just added the site to their 'acceptable' list. I did a traceroute >to why.net and noticed that it is very close to me, coming off of >SprintNet... probably the same situation. Internexus.net has been added to the list. The heuristic that the MIT site enforces is as follows: o To get access you must properly answer some questions regarding export control law and licensing. o Your host must have an "inverse" DNS mapping so we can learn its name. o Your host's name must end in either ".EDU", ".COM", ".MIL", ".GOV", ".US", or ".CA". *or* Be on our exception list. All the ".NET's" and ".ORG's" need to be "excepted." Maintaining the exception list has turned out to be a serious problem. I receive roughly 20 messages a day from people needed to be added. To make matters worse the exception list has to be maintained in two different locations in two different formats. I just broke down today and automated the management of the lists. Unfortunately the only thing I can do for people whose machines do not have an inverse DNS mapping is to send them personal copies via e-mail. However, I have been too swamped to do this. I am looking into alternative approaches of guarding the FTP site (possibly doing a traceroute or something similar) in a better way that still meets the requirements of maintaining export restrictions. Please remember that I maintain the MIT FTP site in my all too rare spare time. Thank you. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPBCFcUtR20Nv5BtAQEUhAQAnzPlxiXo33DqX0X1m39Xh1I0e7ND332n L4vZlf7T3VDU0jYv1IB/6D3aNvMXo0l8JpsXIxqzaxP5nYgVgm1idx06IgY7T1rJ vVRCIqfFleUFPTS/ndo7jznzr+w7Dq1+5wRU2Oa+ymRICBNHCeEnaxcmx3zs4R6a VEBmc/6w8TQ= =vFSt -----END PGP SIGNATURE-----

1 0

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

17 Dec '03

> > People employing systems like PGP are already advised to use them > > on private machines, with only one user, and untampered-with > > binaries. > > Timings like the ones listed are trivial to take in establishing > things like SSL sessions, or Photuris sessions. The danger is to > online protocols, not to PGP. > Perry Loathe as I am to disagree with Perry :-), is it really 'trivial' to take these timings in an online protocol? Paul writes on the DH example: ------------------------- A preliminary implementation of the attack using the RSAREF toolkit[8] has been written. RSAREF scans across the exponent from MSB to LSB and does two exponent bits at a time, so corresponding adjustments to the attack were made. Using a 120-MHz PentiumTM computer running MSDOSTM, a 512-bit modulus, and a 256-bit secret exponent, processing times ranged from 392411 microseconds to 393612 microseconds and closely approximated a normal distribution with a mean of 393017 microseconds and a standard deviation of 188 microseconds. -------------------------- Note that the range is 1201 microseconds and for RSA: -------------------------- RSAREF's modular reduction function with a 512-bit modulus on the same 120-MHz PentiumTM computer takes an average of approximately 17 microseconds less time if c is slightly smaller than p, as opposed to slightly larger than p. Timing measurements of many ciphertexts can be combined to detect whether the chosen ciphertexts are larger or smaller than p. ------------------------- The range here is 17 microseconds. Paul notes: --------------------------- Random delays added to the processing time may increase the number of ciphertexts required, but do not completely solve the problem since attackers can compensate for the delay by collecting more measurements. (If enough random noise is added, the attack can become infeasible.) -------------------------- In a 'real' system, there is a lot of unpredictable variation in the timing of the signal. Sources of such noise include routers, and other sessions on the server (any decent server these days is multi-tasking, and can handle multiple connections simultaneously). On top of that, real protocols have a lot of processing overhead, looking up certificates and keys, generating MAC hash values, etc, many of which are difficult to predict. I tried pinging some machines to look at the slop in the roundtrip times. I have not checked traceroute, but for what it's worth, I'm in central Massachusetts. elnath (local to my lan) <10 ms rtfm.mit.edu (20 miles) 10-21 ms iii1.iii.net (FreeBSD on a 120MHz P5, 35 miles) 100-200 ms utopia.hacktic.nl (Netherlands) 190-781 ms Maybe Paul can give us some figures as to how *much* random noise is enough to make his (very elegant!) attack unfeasible. Note that the range of the random slop I'm getting is hundreds to thousands of times the range of the signal he needs to detect. Statistical techniques, averaging the return times for the same text over many trials may be useful, but the number required to detect a less than 1% variation is going to be high. The attack might be feasible of it can be mounted on a quiet server from a point 'close' (in network terms) to the timing system, and the intervening network segments are also fairly quiet. I don't think random users are going to crack the Dilbert Store, however. Speaking for myself.... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: NIST GAK meeting writeup, part 3 of 3
by Pat Farrell 17 Dec '03

17 Dec '03

I appologise to the list for the character mangling in the original posting. I wrote it in Word so I could spellcheck it, and I couldn't turn OFF the idiotic smartquotes. I've placed a cleaned up, fewer typo, and hyperlinked version out on my NIST page, http://www.isse.gmu.edu/~pfarrell/nist/pdf.nist2.html jim bell <jimbell(a)pacifier.com> writes: >> Geoff said that they may want legislation support for >> protecting against illegal release of keys, failure to release, etc. > Pardon me, but since this "key escrow" system was always claimed to be > "voluntary," then how can there be any kind of legal penalties associated > with "failure to release" those keys? It was Geoff G. talking, not Mike Nelson or Ed Appel. The difference is critical. Mike and Ed have some political savvy. My best friend Geoff does not. I believe that Geoff has never bought into "voluntary" as a concept. EPIC successfully FOIA'd papers from the FBI saying that they will change their tune when/if there isn't sufficient compliance. Mike and Ed are political enough to know that they can't sell this if they push too hard. Geoff isn't. The podium had a light that showed green/yellow/red lights. These let the speakers know how much time was left. For the morning, since only NIST/NSA/FBI/... folks talked, they didn't bother to reset the light. It was red all the time, altho it blinked occasionally. Ed took the mike, and asked "what is the red light for? Does it glow red whenever someone from the Government is lying?" It got a good chuckle. It was probably also close to being true. Ed and Mike understand the audience, Geoff never will. > Which raises another question: Let's suppose I owned a product based on > CKE, and I went to the escrow agent and said, "This escrow is voluntary, > right? If so, erase my key in your possession." > > Not that I'd trust them to do so, but how "voluntary" can a system be if > people can't volunteer out of it? It isn't voluntary for export approved software. The word voluntary is not in the criteria. It is only voluntary if domestic users foolishly choose to buy GAK'd products. So don't! Criteria #2 says "...cryptographic functions shall be inoperable until the key(s) is escrowed in accordance with #3." Worse, IMHO, is criteria #9, which states " ... cryptographic functions shall interoperate only with key escrow cryptographic functions in products that meet these criteria..." The interoperability issues stayed muddy. The government didn't spend much effort making it clearer. The karma seemed to be that if you had two products, say Webscape 128 and Webscape 64/Gak, selling 128 domestically and 64/GAK exported, that you can't make Webscape128 interoperate with 64/GAK unless the Webscape128 keys are GAKed. Part of this is burried in agent criteria #6, "6. Escrow agent entities that are certified by the U.S. government shall work with developers of key escrow encryption products to develop and support a feature that allows the product to verify to one another that the product's keys have been escrowed with a U.S.-certified agent." Looks to me like the software has to chase up the chain of certification authorities (or escrow authorities if you prefer) before it can work. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: Crippled Notes export encryption
by nobody＠replay.com 17 Dec '03

17 Dec '03

"Perry E. Metzger" <perry(a)piermont.com> writes: >> >By the way, I really think Netscape should simply ship Jeff and other >> >people to the Amsterdam office or wherever else seems reasonable and >> >> That won't work -- they gotta hire non-US persons to do the work. > >There are plenty of good foreign crypto people. One of them already has implemented SSL...

1 0