December 2003 - cypherpunks-legacy

Note on "Barring Netscape"
by Richard Charles Graves 17 Dec '03

17 Dec '03

The Microsoft Internet Explorer sends the user-agent "Mozilla 1.22 (compatible" to hte server, which triggers an incorrect response from, e.g., www.c2.org. This little fraud has the potential to make you look silly if left unexplained. If you get the string "compatible;" (or Compatible;?), you should instead pop up Netscapisms that show that Microsoft is lying. Or maybe Billisms. <font face="Symbol">, which affects only MSIE, might be appropriate. -rich

3 2

Re: The "Future" Fallacy
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:24 AM 12/6/95, blancw(a)accessone.com wrote: >From: Duncan Frissell > >Bill Gates (like Mister Newt before him) committed what I call the Future >Fallacy in "The Road Ahead." Page 106. > >"Soon any child old enough to use a computer will be able to transmit coded >messages that no government on earth will find easy to decipher." >................................................... > > >Billg is an optimist. > >What's wrong with this picture, Duncan? I found nothing wrong or incorrect with the quote Duncan attributed to Bill Gates (I haven't read Gates' book). I couldn't understand Duncan's koan, shrugged, and moved on. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

6 6

Re: Geodesic Payment Systems? (was Re: Meeting notes from ANSI X.9 Meeting onElectronic Payment)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Once again, Hettinga shoots from the hip, and hits an expert instead... ;-) At 9:07 AM 12/5/95, Nathaniel Borenstein wrote: >There are some interesting unspoken assumptions here. To calculate >anyone's "cost" on a transaction requires the complex amortization of >costs over many transactions, with assumptions/projections about the >transaction volume. I have no idea where you came by either of your >numbers, MTB's or FV's, but I can tell you that your guess about FV is >off the mark. And I'm sure that MTB is no more eager than we are to >publicly dissect all the underlying cost structures, so I have no idea >what the 50 cents that you cite really means. The 50 cents actually comes from this week's InfoWorld, Bob Metcalfe's column. I have know idea where he got the 50 cents, but he did say digital cash, so i expect that he means MTB. >To be perfectly clear: our minimum service charge is 30 cents, not 5 >dollars. If we didn't think it was worthwhile to take transactions that >small, we wouldn't do so. Fine. Are we including the cost of the credit card transaction to the consumer? Fees, interest, that stuff? There are lots of hidden costs in a book entry system. With a bearer-certificate system, the price is the spread between the certificate's bid and asked prices for (a traveller's check, for instance, is asked at a primium, and redeemed at face value, for instance. That's all the cost of using them.) >A true geodesic structure is self-supporting and self-structuring. A >cryptographic infrastructure can and should be similar, I agree >completely. However, a *monetary* infrastructure needs convertability, >and the points of conversion are always the best targets of attack for >criminals. (I've been casting about for an analogy to physical >geodesics, and it's hard to find one. The best I can come up with is to >imagine that in order to convert a carbon buckyball to a more >conventional set of carbon molecules, you had to do it through a service >bureau that was capable of error, fraud, or subversion by outside >criminals. This would ONLY matter if you ever wanted to do such >conversions, but it would matter a lot then, especially if you had to >suffer a serious financial loss if you got the wrong carbon molecules at >the end of the process.) Sometimes I feel like I'm beating this geodesic metaphor like a dead horse sometimes... ;-). > >IF you wanted to settle for a totally non-convertible economy (like >rubles in the old Soviet Union, or like the LETS system on the net >today, as I understand it) then you could build it geodesically. Really? > But if >you want to be able to convert back and forth between Internet payment >systems and non-Internet payment systems, it can never be truly >geodesic. It will always be attackable at the points of conversion. >(You may "trade digital certificates", but how do you know the ones >you're receiving were obtained for legitimate real-world value?) >Because of this, the underwriting financial institutions, who have a >very reasonable desire to limit their own risk, will inevitably seek the >protection-by-traceability offered by something less than perfect >anonymity. We may not like it, but it's a very natural position to be >taken by those who are actually bearing the financial risks at the point >of conversion. That may be true, Nathaniel, but just because the people who bring the money off the net need to be identified to the digital cash underwriter's (actually the underwriter's bank's) satisfaction, doesn't mean that the trades on the net can't be totally anonymous. We've gone over this before. Let's build a model to talk about this, and then you'll see what I mean. Suppose I open an anonymous bank account with ATM card. Then, on the net, I buy digital cash from a digital cash underwriter. The web-page reads my ATM swipe and PIN, and then pumps it (without the underwriter being able to read it) through to my bank, who says to the underwriter, "Yup, there's money here, send it to him, and I'll wire it you (now/overnight/whatever)." The digital cash underwriter then issues me my digital cash, and I put it on my hard drive. I buy stuff on the net. I sell stuff on the net. Sometimes I go online with the trade to check my buyers' cash, sometimes I don't. Element of risk there, but this risk can be made accountable. It's probably always going to be cheaper to do offline transactions, but there's the possibility that when I cash in that money, it has been spent already. Fair trade. It's probably quantifiable and thus can be dealt with. We won't know till we have data. Being an astute businessman (you can tell this is a model, right?), I end up with positive cashflow. So, that money I don't invest with a portfolio manager on the net by buying anonymous bearer certificates for his mutual fund, ;-), I decide to take off of the net and buy Netscape puts, March 1996, $10. So, I go to the underwriter's page (maybe I go to multiple underwriters' pages, or maybe there's an enterprising third-party money changer who honors all comers for a cut), and I cash out. I swipe my ATM and punch my PIN, and my bank says to the underwriter "OK, I know that account, how much are you sending me?", and the underwriter says how much, and how and when the money would arrive (wire? Rollerblade messenger? bunch of militia types in a purple Hummer?, anyway...). And there's money back off of the net. In this model, there's no reason why I can't send an anonymous software agent to buy stuff for me, why I can't buy anonymously or sell anonymously. So, given that model, what's the problem? Now, I've also been thinking about something else. Wei Dai has been talking about how anonymity will always cost more, and certainly, in the model above, there's a certain risk with doing off-line transactions. You don't know if the cash in the transaction is double-spent, like I said above, but that "special stuff" has to be done to accomodate anonymity, which will always cost more. I'll come back with a whole blather on this next week when I get back from the CyberDog Kitchen (I'm here, and Gromit says "hi"), but I think it comes from what the default mechanism for commerce is going to be, threaded, audit-trailed x.blabla or anarchic, geodesic, bearer-certificates. I bet you can guess where I'm going to come down on this... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

Re: Timing Attacks
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:15 PM 12/11/95 -0500, "Rev. Ben" <samman-ben(a)CS.YALE.EDU> wrote: >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. ... >Am I missing something, or does this attack only work in a lab? It works much better in relatively controlled environments - smart cards, for example, are usually both slow and not busy doing other things, plus you can get a bunch of them and analyze the variance in performance across cards. The Usual Suspects say this does appear to affect Fortezza, plus things like digital wallets are obvious targets. If you're clever, you can design smart-card readers that do the measurements for you, and convince people to use them. The attack also works better if you can try it multiple times with the same numbers to work around random latency; the lowest number is closest to real. Running on time-shared machines increases randomness a lot (though if the Bad Guys have an account there, they can watch the machine's performance more closely.) On the other hand, running on shared machines has its own set of security risks, though they're better places for Diffie-Hellman systems than secret keys - but Diffie-Hellman needs authentication to be safe against MITM, and therefore there's still a secret key for that. Interesting times.... We've all been discussing whether there'd be some major theoretical-mathematics breakthrough, and along comes an engineering attack. #-- # 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

Announce: Timing cryptanalysis of RSA, DH, DSS
by pck＠netcom.com 17 Dec '03

17 Dec '03

I've just released details of an attack many of you will find interesting since quite a few existing cryptography products and systems are potentially at risk. The general idea of the attack is that secret keys can be found by measuring the amount of time used to to process messages. The paper describes attacks against RSA, fixed- exponent Diffie-Hellman, and DSS, and the techniques can work with many other systems as well. My research on the subject is still in progress and the current paper does not include many of my findings. I will eventually publish a full paper, but am releasing a preliminary draft now to alert the community as quickly as possible. A copy of the abstract is attached at the end of this message and the full text can be downloaded in PostScript format from: ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps.gz I've also made an HTML version which is accessible at: http://www.cryptography.com (The HTML uses subscripts and superscripts which aren't supported in older web browsers. The PostScript version is the "official" one and looks nicer.) The results have already been seen by Matt Blaze, Martin Hellman, Ron Rivest, Bruce Schneier, and many others. While the full significance of the attack is not yet known, I think everyone who has seen it considers it important (including Netscape who awarded me a $1000 bugs bounty prize). ABSTRACT. Cryptosystems often take slightly different amounts of time to process different messages. With network- based cryptosystems, cryptographic tokens, and many other applications, attackers can measure the amount of time used to complete cryptographic operations. This abstract shows that timing channels can, and often do, leak key material. The attacks are particularly alarming because they often require only known ciphertext, work even if timing measurements are somewhat inaccurate, are computationally easy, and are difficult to detect. This preliminary draft outlines attacks that can find secret exponents in Diffie- Hellman key exchange, factor RSA keys, and find DSS secret parameters. Other symmetric and asymmetric cryptographic functions are also at risk. A complete description of the attack will be presented in a full paper, to be released later. I conclude by noting that closing timing channels is often more difficult than might be expected. Cheers, Paul Kocher ********************************************************************* VERY IMPORTANT: If you send me e-mail, please understand that I probably won't have time to respond to all who write. Please keep messages SHORT and send them to pck(a)cryptography.com (**not** my netcom address -- misdirected messages will be ignored). PGP when used for e-mail is not vulnerable to the attack. Please state in your note whether you would like a reply. ******************************************************************** __________________________________________________________________________ Paul C. Kocher Independent cryptography/data security consultant E-mail: pck(a)cryptography.com (please see above before replying)

1 0

Re: More FUD from First Virtual [NOISE]
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:19 PM 12/11/95 -0800, sameer wrote: >> Maybe Sameer will create a Hack FV page :-) > > FV isn't worth it. > Actually, Hack FV seems pretty pointless. Someone hacks FV, >and a chargeback is issued on the credit card. Big deal. Same old >outdated credit-card based payment systems. > No more secure than credit cards. Besides, if you hack FV you've got the money :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

3 2

Re: Win NT proprietary pw encryption (Was: Re: Windows .PWL cracker...)
by Ted Cabeen 17 Dec '03

17 Dec '03

At 11:39 AM 12/11/95 +0000, you wrote: >Futplex wrote: >> someone quoted: >> Microsoft Knowledge Base article Q102716 says: >> > Storage of the Passwords in the SAM Database >> [...] >> > The second encryption is decryptable by anyone who has access to the >> > double-encrypted password, the user's RID, and the algorithm. The second >> > encryption is used for obfuscation purposes. >> >> Anyone feel like putting together some sample plaintext/ciphertext pairs ? > >This will be really difficult, and in practice rather pointless. NT does >not allow any user, priviliged or not, to gain access to any form (encrypted >or not) of the passwords. They are stored in a protected area of the system >registry that only the OS itself can access. The best that you can do is >to ask the OS whether a given username/password pair is valid or not, and it >took until version 3.51 before MS let you do even that! I took a quick look in my NT registry and you can get access to the Account Manager section of the registry by manually changing the permissions and giving yourself access. I didn't have the time to look at all of the entries in the registry, but there's a lot of stuff there and I wouldn't be suprised if the encryted passwords were available. Of course, you have to be an administrator to change the permissions, but it is possible. _____________________________________________________________________________ Ted Cabeen cabeen(a)netcom.com Finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." cococabeen(a)aol.com

2 1

*fnord* "Encryption Flaw Rattles Security Industry *fnord*
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

"Encryption Flaw Rattles Comuter Security Industry" SAN FRANCISCO - The discovery of a vulvnerability has shaken the computer world's faith in the safe use of the data-security technologies on which most current and planned electronic banking, shopping and "digital cash" systems are based. The vulnerability has been found in a class of technologies known as public-key encryption - designed to provide electronic transactions by scrambling data so they can be read only by people with the proper mathematical keys to the code. The flaw was identified by Paul C. Kocher, a 22-year-old researcher, who demonstrated a way that an electronic eavesdropper who is able to monitor the repeated process of unscrambling the incoming messages could figure out the private key. It can be done by repeatedly keeping track of the precise length of time it takes to unscramble each message. --From TimesFax, Mon. Dec. 11 Internet Edition

1 0

Re: More FUD from First Virtual
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:51 AM 12/10/95 -0500, Nathaniel Borenstein <nsb(a)fv.com> (Tense Hot Alien In Barn) wrote: >In any event, I could write a virus that sits in >front of the e-cash program and steals your keys when next you run the >e-cash program. Software's just too easy to fool. That's why I regard >the risk of catastrophe as being fairly large in software-based e-cash >schemes. How is this different for an ecash program vs. a First Virtual email acknowledgement program, where either a (really hairy) virus, or, more practically, an active email interloper could fake FV acks? While hardware may be the best encryption solution for the average user (as you say, and I think I agree with you), it needs to have some password interface such as a small keypad on the front of the smartcard, to prevent its usability after theft. Of course, there are problems with digicash as well; my Digicash play-money account thinks it's empty (in spite of having half a dozen coin-looking files), and doesn't recognize any of the half-dozen passwords I've guessed I might have used with it, so I'm not able to use Sameer's digicash-powered remailer. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

4 3

*fnord* "Encryption Flaw Rattles Security Industry *fnord*
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

"Encryption Flaw Rattles Comuter Security Industry" SAN FRANCISCO - The discovery of a vulvnerability has shaken the computer world's faith in the safe use of the data-security technologies on which most current and planned electronic banking, shopping and "digital cash" systems are based. The vulnerability has been found in a class of technologies known as public-key encryption - designed to provide electronic transactions by scrambling data so they can be read only by people with the proper mathematical keys to the code. The flaw was identified by Paul C. Kocher, a 22-year-old researcher, who demonstrated a way that an electronic eavesdropper who is able to monitor the repeated process of unscrambling the incoming messages could figure out the private key. It can be done by repeatedly keeping track of the precise length of time it takes to unscramble each message. --From TimesFax, Mon. Dec. 11 Internet Edition

1 0