December 2003 - cypherpunks-legacy

Third generation privacy
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

On Dec 11, 1995 13:07:22, '"Ed Carp (ecarp(a)netcom.com)" <khijol!netcom.com!ecarp>' wrote: > >Another, not-so-obvious reason to encrypt stuff, especially stuff >that goes out over the net, is that folks can suck your email off the >net and gather all sorts of useful information. This has all kinds >of annoying implications, especially for people who gather >demographics and other data for constructing email lists for sale. > >-- short ed > Another related issue is what I'll call "third generation" privacy. This exists when I want privacy not for myself or even the person with whom I'm communicating but to protect the privacy of innocent third parties. E.g.: Grandpa is getting senile and I'm communicating with a second family member on how we should handle the problem; My friend Jane was just raped and I'm communicating with a mutual friend about how we can help her. The anti-freedom forces have tried to define the parameters of the debate inside the boundaries of the "four horsemen." We need to understand that we do not have to remain within those false boundaries and, in fact, it is very good not to. --tallpaul

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: Re[2]: Timing Cryptanalysis Attack
by David E. Smith 17 Dec '03

17 Dec '03

At 10:30 PM 12/11/95 CST, Martin Diehl wrote: > 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_ Does it necessarily matter whether the random delay time is true-random? The idea is to obfuscate the time of the whole computation. As long as you don't base your random numbers on the system clock, it should serve its purpose. (I omit the system clock because timing seems to be the nexus of the whole attack, so we can safely assume that the clock's data, and thus its source of "randomness," can be predicted. ----- David E. Smith, c/o Southeast Missouri State University 1210 Towers South, Cape Girardeau MO USA 63701-4745, +1(573)339-3814 PGP ID 0x92732139, homepage http://www.midwest.net/scribers/dsmith/ Quote: "And if we change, well, I'll love you anyway" - Alice In Chains Dec15-Jan15: (618)244-3340/2209 Perkins, Mt Vernon IL 62864

1 0

PAY-OFF TIME FOR BUG-BUSTERS, NETSCAPE PLEDGES "DOGFIGHT"
by OpsAn＠gnn.com 17 Dec '03

17 Dec '03

PAY-OFF TIME FOR BUG-BUSTERS, NETSCAPE PLEDGES "DOGFIGHT" Netscape Communications has awarded two software sleuths $1,000 each for finding security gaps in its Netscape Navigator 2.0 software. The company also awarded gifts to 50 other contestants in its "Bugs Bounty" program for identifying non-security problems. (Wall Street Journal 11 Dec 95 B7) Meanwhile, Netscape has vowed to wage a "dogfight" with Microsoft in setting standards for Internet software. CEO James Barksdale says his company will continue to develop products that operate independently of any particular computer operating system, noting that, "We offer freedom to the masses. It's a tough fight -- I'll grant you that -- but we're brave. We're well financed. We believe that God is on our side." (Investor's Business Daily 11 Dec 95 A7)

1 0

Timing RSA and Certificates worth ??
by lyalc＠mail.mpx.com.au 17 Dec '03

17 Dec '03

My limited mind induces me to think that a certificate become subject to timing attacks on the RSA private signing key. This appears to meet the main critieria of fixed data (for instance, a bank's certificate in/on ecash), processed widely by a small group of machines (eg a subset of customers) on inherently untrusted machines (home PC's) which may or may not have the right software/operating system parts. Certificates in general, do not appear to lend themselves to "blinding". In this case, certificate verification processes seem flawed and highly unreliable. eg a merchant gets lots of data containing a bank(s) certificate, and probably encrypted data. Is this the death knell for STT/SEPP and ecash/echeque systems ??? Some ramblings and thoughts. lyal

1 0

Re: Timing Attack Paper
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:39 PM 12/11/95 CST, gibo wrote: >I went to > >http://www.cryptography.com/timingattack.html > >and found the whole thing to be totally incomprehensible from >a layman's point of view. I apologize for having not read >"Applied Cryptography", which might have made the abstract a >simpler read - but even if I had I'd have been baffled by a >lot of the terminology and equations in this paper. > >Can anyone post a brief summary which explains the essential >workings of the attack? I'd be very grateful. Briefly, most public-key calculations are _slow_, and use 512-2048-bit numbers which get represented as arrays of machine integers. The amount of time they take depends on the values you're multiplying together, especially because the algorithms used to do the arithmetic less slowly take shortcuts whenever possible to avoid unnecessary work. If you watch the time that it takes for a machine to do calculations using its private keys, for some algorithms you can guess a bit or two of the key. If you're clever, and have the ability to feed the victim different numbers for it to calculate on (e.g. make a bunch of connections using Diffie-Hellman), you can guess different bits each time, and gradually get the whole thing. It helps to watch this a number of times to get better statistics, so you can tell what's real calculation and what's just speed-randomness. Obviously, it also helps if you're running a program on the same machine as the target you're trying to hit, but you can still gain some information if you're running across a network and having to estimate random network delays. In these cases, you just have to watch longer to get stats. A common algorithm for doing modular exponentiation (the core of the Diffie-Hellman and RSA algorithms) looks like this: To calculate y**x mod m (all this arithmetic is multiple-precision) (and maybe there's an off-by-one error or two in this :-) This uses successive squaring to do the calculation in log2(x) time instead of just doing x multiplies by y, which would be very slow since x is typically 500-1000 bits long... Remember that multiplying two 1024-bit numbers typically involves multiplying two arrays of 32 numbers 32 bits long, which takes 32*32 or 1024 multiply steps. And modulo calculations are also slow. prod = 1 square = y log2x = number of bits in x for i = 1 to log2x+1 { if (x odd) then { prod = prod * square if ( prod > m ) then prod = prod mod m } # else if (x even), don't bother square = square * square if (square > m) square = square mod m x = x / 2 } You can figure out the timing for the squaring calculations yourself. Since you get to pick y, you can manipulate it to guess a bit about how long x is, and notice from the different timings how many times there was a prod*square calculation (which tells you how many bits were odd), as well as how many prod mod m calculations. You can get a certain amount of defense by keeping around prod1 and prod2, and calculating prod1 = prod1 * square (the real value) for odd and prod2 = prod2 * square (a dummy you'll discard later) for even, and doing something useful to obscure the mod m calculations, like keeping a dummy around to divide if prod1 or prod2 is less than m. Aside from slowing things down by 50%, if you're not careful, there's still information that leaks from the timing. For other algorithms, sometimes the calculations you've got to do timings on are more subtle, like DES, but you can still often guess things, and Paul gives a bunch of calculations for these. They're more statistical, since the effects you're chasing are subtler, but you still get information. #-- # 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

Re: Timing Attacks
by eli+＠GS160.SP.CS.CMU.EDU 17 Dec '03

17 Dec '03

samman-ben(a)CS.YALE.EDU writes: >I'm not so sure I see the great usefulness of this attack. It appears to be more practical than 99 percent of the "weaknesses" that get published. Not bad, I'd say. It's also a very cute attack; I'd never have guessed a priori that you could get that many key bits from timing data. >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. "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.)" [extended abstract, p. 5] Sufficient network noise *might* make the problem go away, in some cases, but that's a weak sort of claim to make about a cryptosystem. (What if the attacker tries at six in the morning, or cracks a machine local to you, or just gets lucky?) You might put your server behind a time-quantizing firewall... Also, it's not just networked machines. Smart cards may have a hard time defending themselves against hostile card readers. They're slow already; the user may not appreciate the extra time spent for obfuscation. (This depends critically on the numbers, of course.) -- Eli Brandt eli+(a)cs.cmu.edu

2 1

Plaintiff's Opposition in Karn vs State Dept
by Phil Karn 17 Dec '03

17 Dec '03

On Monday, December 11, my attorneys filed a Plaintiff's Opposition to Defendants' Motion to Dismiss in the case of Karn vs US Dept of State et al. I have HTMLized our filings and added them to my web page. Please feel free to peruse them. Also, let me know if you spot any obvious typos; I had to do quite a bit of manual editing, particularly in the footnotes, to make the result look good in HTML. The government now gets the chance to answer our opposition. They were originally scheduled to do by December 13, but since our own filing was delayed over the weekend by the judge's concurrence the government will probably get a few extra days to respond. Note that we have asked to make oral arguments on the motion. I'll let everyone know if or when this will happen. The web page is: http://www.qualcomm.com/people/pkarn/export Phil

1 0

Re: e-Cash: CAFE vs. Mondex
by Matthias Schunter 17 Dec '03

17 Dec '03

Dear Mr. Klur, I'm member of the CAFE consortium but I can not answer your question. As far as we know, the details of the Mondex protocols are still confidential (or only available under a non-disclosure license). However, I can give you some details about CAFE. The CAFE system is a cheque based system. This means that the customer receives an electronic chequebook, where each cheque is (blindly) signed by the bank. During each payment the customer has to use one of these signed cheques. Some of its properties are: secure Breaking the card results in a limited gain, since soon the customer will run out of cheques (Mondex' security is quite likely only based on tamper-resistance). open Due to the open public-key architecture used, the system is open, e.g., it supports multiple-issuer, multiple-currencies. One part of this openness is the public availability of the specifications. practical It provides full loss- and fault-tolerance (i.e. if you loose your wallet you're able to recover your electronic money) and supports fast micropayments (e.g., for phone ticks). privacy-protecting The privacy of the user is protected. We will soon publish our full protocol and architecture specifications. A short 50-page summary is already available (PostScript). Additional information may be found at http://www.informatik.uni-hildesheim.de/~sirene/projects/cafe/index.html Please ontact me, if you are interested in this abstract or if you have additional questions. Regards, M. Schunter --- Forwarded mail from "David Klur" <dklur(a)dttus.com> Date: Mon, 11 Dec 95 12:13:48 CST From: "David Klur" <dklur(a)dttus.com> To: cypherpunks(a)toad.com, WWW-BUYINFO(a)allegra.att.com Is the Cafe e-cash system different than Mondex? If so, how? Also, does anyone know when the Mondex trial will start in Delaware? ---End of forwarded mail from "David Klur" <dklur(a)dttus.com> % Matthias <Schunter(a)acm.org> Uni Hildesheim +49(5121)883-788 fax-732

2 1

Blinding against Kocher's timing attacks
by ljo＠ausys.se 17 Dec '03

17 Dec '03

Ron Rivest wrote (at sci.crypt): >The simplest way to defeat Kocher's timing attack is to ensure that the >cryptographic computations take an amount of time that does not depend on the >data being operated on. For example, for RSA it suffices to ensure that >a modular multiplication always takes the same amount of time, independent of >the operands. > >A second way to defeat Kocher's attack is to use blinding: you "blind" the >data beforehand, perform the cryptographic computation, and then unblind >afterwards. For RSA, this is quite simple to do. (The blinding and >unblinding operations still need to take a fixed amount of time.) This doesn't >give a fixed overall computation time, but the computation time is then a >random variable that is independent of the operands. Does anyone know whether David Chaum's patent on blind digital signatures extends to this application? Kind regards, /Lars Johansson ljo(a)ausys.se http://www.ausys.se/defaulte.htm

1 0