December 2003 - cypherpunks-legacy

Still more on the Digicash protocol
by daw＠guaymas.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ian & I were talking about the Digicash protocol some more. Hal has pointed out that payments & deposits with a wildcard in the payment_hdr should NOT be sent in the clear, since they can be stolen by any passive eavesdropper. Ian has pointed out the same problem with cancellations: the payer_code should NOT be sent in the clear, since any passive eavesdropper can grab this info and steal the corresponding payment. Sadly, the current Digicash client DOES send those items in the clear (without even warning users to avoid wildcards). Why? Anyhow, the obvious solution is encryption. Our new observation is that encrypting deposits & cancellations with the mint's public key is not enough to solve the problem. To see this, recall how the public key encryption works: a session key for a bulk cipher is encrypted under the public key, and the data (e.g. userhdr, payment_hdr, coins, ...) is encrypted under the bulk cipher. Digicash hasn't told us yet what bulk cipher they use, but let's assume for concreteness they use RC4. Now I'm an attacker -- I want to modify userhdr.userID -- and then the mint will accept the payment and deposit the coins into the wrong account. But this is just easy for an active attacker -- I just flip bits in the ciphertext! (Presumably I can guess fairly well what plaintext value is expected for the userhdr.userID field.) This is just a corollary of my Pet Peeve for protocol designers: Don't use encryption when you want message authentication; with encryption, you should only count on confidentiality! Ok, so you mention that maybe Digicash uses DES-CBC or somesuch instead of a stream cipher like RC4. I'll briefly note that while the attack isn't so trivial anymore, DES-CBC ciphertext is not tamper-proof -- again, encryption does not provide message authentication. Another nitpick from your friendly neighborhood techno-geek. I noticed that signatures (when used) don't cover the headers. Since the mint uses header information to make important decisions (e.g. the userhdr.userID field specifies who's account a deposit should go to), shouldn't this be signed, just as a matter of ordinary everyday paranoia? While I'm ranting, let me also remind you of a problem Ian discovered earlier through reverse-engineering: the payment & deposit messages aren't encrypted, and they send payee (e.g. shop) identity payer's and payee's banks payer's currency-of-choice amount of money transferred description of the product time of payment in the clear, accessible to any passive eavesdropper. With traffic analysis, if payers use the default TCP connection, all this information about them can be compiled. If I target a payer, I'll probably be able to record all his transactions (unless he's using remailers or pipenet). If I sit outside a small business, I can compile a dossier on its buying habits. Worse still, anonymity for the shop is worse with Digicash than with real cash. If I pay you real cash on a secluded street, you're fairly anonymous. If I pay you Digicash over the Internet, any passive eavesdropper could be recording your identy and the whole transaction. Blech. So Digicash's product does all sorts of neat crypto to provide you with anonymity from the bank, but doesn't do much to provide anonymity from eavesdroppers on the Internet. This is exactly backwards from how I'd prioritize -- I'll trust my bank to keep me private long before I'll trust messages sent in the clear over the Internet (on a virtual postcard) for all to see! Blech. So, what should Digicash be doing to remedy these problems? * always set up an encrypted, authenticated connection before sending any messages in the Digicash protocol. (Yes, this means shops will need to have certificates if you want to avoid a man-in-the-middle attack. So be it. Most online shops will be using SSL, and thus have a certificate anyhow. You can safely punt on the authentication between customer <-> shop if you're not worried about active attacks.) * add a big warning to the documentation: users should not use wildcards in payments (unless they know the dangers & are encrypting with e.g. PGP). * sign the header stuff too. * continue specifying the protocol at a deeper level, like you promised (and throw in source for security-critical modules too, eh? :-) - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMMYgtioZzwIn1bdtAQHx9QF+J6qWEqWcsaoVOUQ3i9qaVF8MgYdztCLg 9si9YDnjqPnFEsGTHYBjZXB8/TpOfiZe =cBGu -----END PGP SIGNATURE-----

1 0

Re: latest librand source now av
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

In .cypherpunks, Matt Blaze <mab(a)research.att.com> writes: >[Sorry if this is a duplicate; my machine had a bogus sendmail.cf >when I first sent this.] > >Souce code for the latest version of librand (a random >number package based on event interval variations) for >Unix-like machines is now available in: > ftp://ftp.research.att.com/dist/mab/librand.shar > >There are no restictions on use or distribution of this >code, which was written by Matt Blaze, Jack Lacy, and >Don Mitchell. > >-matt > why the FUCK would anyone want to use random number code from at&t, (and mister nescape GAK apologist himself)? this the code that was broken by french student for christs sakes. and tell us the truth about the restrictions, next time, bozo. asshole. cypherpunks write code themselvess!!! --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

2 1

Re: NIST GAK export meeting, short version
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:26 PM 12/5/95 -0500, Futplex <futplex(a)pseudonym.com> wrote: >> and on the 64-bit issue, that the government is "not certain it will >> work." he says they "want to see it implemented and want to see ... >This answer sounds rather silly to me. Do they seriously doubt that the >escrow mechanism works (modulo MAB's observations about the LEAF), or expect >us to believe that they do ? Clinton Brooks' comments cited later by Pat >suggest a certain acceptance that enforcement will have its problems >(e.g. strong crypto tunnelling), but perhaps Greiveldinger somehow doesn't >officially share that view. Is there another interpretation of "working" >I'm missing here ? "Works" means a lot of things, even if you limit the discussion to official court warrants requested with honest affidavits. The code is supposed to discourage tampering, but suspects may still successfully disable GAK. Escrow agents are supposed to deliver the correct keys successfully without losing them (or storing them safely in the basement next to the cyclotron), and they may not always provide 7x24 access (or may charge extra for it, as well as charging for their lawyer's review of the warrant.) Or the escrow agents may be multinationals that store their files off-shore. Or the SECRET cleared escrow employee may have quit, making it more difficult to handle classified requests. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: NIST GAK export meeting, short version
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:11 AM 12/6/95 -0400, pfarrell(a)netcom.com wrote: >They claimed it was needed so that they can serve a court order >that is SECRET. .... >The main area that they claimed was for FISA orders. Maybe this is just an artifact of Pat's wording, but this sounds like there may be classified court orders other than FISA? > Plus, since you have to be a US citizen to get a clearence, > how can there be approved foreign escrow agents? By deals with the foreign governments, presumably reciprocal. The US would allow export of software using the escrow keys for Banque du Commerce et Credit Internationale - Paris, if the bank and the French spooks signed an agreement for escrow access, and in return the US would probably agree to give the French access to some US-escrowed keys (with proper requests, of course.) >And the usual, why in hell would a competent spy use >crypto escrowed in the US? Competent spies appear to be a surprisingly small fraction of even government-employed espionage personnel, or maybe long-term espionage is just inherently difficult the Soviet Empire, Nazi Germany, and WWII Britain had all identified most of the spy rings operating against them. Philip Agee's article on how to identify the CIA agents in a US embassy may have surprised the CIA, but wouldn't have given any significant new information to the KGB. (They might have been surprised he'd _say_ it...) And amateurs and newcomers to the business aren't always that good. Also, maybe a spy would be using GAKed crypto to avoid attracting attention. Much of espionage, especially emerging economic espionage, primarily uses open-source information; there's nothing too secret about sending the latest SAIC want-ads from EE Times back home, but the CIA may learn what targets you're watching by watching enough of your traffic to guess at your filtering criteria. And sometimes you're just stuck on the Beltway and have to use your car phone to say you'll be a bit late dropping off the secret plans. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Solution for US/Foreign Software?
by Bill Stewart 17 Dec '03

17 Dec '03

>>>1. Write a program with limited encryption (40 bit?), with the encryption >>>module in a file external to the main program. >>>2. Get export approval for this program. >>>3. Write a module which replaces the encryption file, increasing key size >>>to whatever you REALLY wanted in the first place. (128-bit IDEA, 2000-bit >>>PGP, etc.) >>>4. Ship that new module with the old software to US customers. >>>Naturally, that new module will "leak," so anybody who buys the old Tim May replied >>"Crypto hooks," basically the scheme you are proposing, were thought of by >>the authorities and are not a bypass of the crypto export laws. I had interpreted the suggestion differently - rather than a system with user-accessible crypto hooks, the manufacturer could ship a binary patch upgrade for US customers to install. The internal design would presumably have crypto hooks (i.e. subroutine calls); they can't ban that. Of course, if you follow this strategy, get export approval for version 1.0, and ship the US-only patch as 1.1, getting export approval for version 2.0 may be a shade more difficult... #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

2 1

SEQ_uel
by John Young 17 Dec '03

17 Dec '03

Science, Dec 1, 1995. "The Evolution of Molecular Computation." By Willem Stemmer. Comments on the limitations of Leonard Adleman's and Richard Lipton's DNA-computation research compared to the utility of sequence evolution computation. Although DNA sequencing of the selected solutions poses a practical problem for molecular computation, this drawback does not exist for computation with genetic algorithms or for in vitro evolution or computer simulations of natural evolution, called artificial life. Sequence evolution appears to be a useful general tool for solving many complex problems, whether the solution is a number, sequence, program, or structure. SEQ_uel (6 kb)

1 0

Re: Why Netscape employees should not leave
by Jeff Weinstein 17 Dec '03

17 Dec '03

Adam Shostack wrote: > This leaves us to ask, why GAK is such a big deal at NIST, if > CKE will get them most of what they want? First, they haven't > realized that CKE is most of what they want. Second, they're worried > about the extra 10%. Drug dealers and terrorists not using it. (This > points towords an eventual mandate for GAK, even if it starts out > voluntary. Many have noted this.) Third, they've invested so much > energy in the fight for GAK that they're emotionally tied to the idea, > and they can't say 'well this would be almost as good.' It also allows them to stall on increasing the clearly inadequate export key size of 40-bit, while they are working on "an alternate solution". Given the overwelming negative response from industry over GAK, it may be nothing other than a delaying action. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

1 0

Re: Solution for US/Foreign Software?
by daw＠boston.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <199512062229.RAA16714(a)universe.digex.net>, Scott Brickner <sjb(a)universe.digex.net> wrote: > > I agree. It does bring to mind an idea, though. Netscape builds an > exportable system by choosing a random 128 bit number and then just > including 88 bits of it in plaintext. > > This means one of two things. Either there's a field which holds the > "key", but the export version stores 88 bits plain + 40 bits cipher, > and knows this structure, or there's a field which holds the 128 bit > enciphered key, and a second field which holds the 88 bits of plaintext > key. > It's the former (in SSL v2.0). I looked into this, because the former version can be vulnerable to related-key attacks, if not done right. SSL v2.0 does it right. (In particular, SSL v2.0 hashes both the 88 bit salt + 40 bit secret to get all the cipher keys.) > > In the former, the patch would be more significant, but still possible. > You'd disable the "write the plain" part and extend the "decode the > cipher" part to decode all 128 bits --- probably just a loop test. > (And you'd have to change the cipher type from RC4-40 to RC4-128.) Or write a local proxy to convert from RC4-40-salted to RC4-128. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMMZCbSoZzwIn1bdtAQF9xAGAqkg5VzChucF3FasK2pYVxg1D5F3lsnSP CFWsp+MbXKqTe71iznBvtg246xWPLohe =XM3W -----END PGP SIGNATURE-----

1 0

Re: News on Congressional Debate on Exon
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Tim wrote: >>If the Exon Bill really does go into effect, and age limits on access are >>imposed, I'll be looking for what we've always joked about: the >>"Information Superhighway Driver's License." To be perfectly honest, whenever I talked about this topic I wasn't joking. Prepare to see "felony Internet access" on the books before long. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

unsuscribe
by KLEMEN RAMOVES 17 Dec '03

17 Dec '03

plz..unsuscribe me.. klemen@lj klemen@Lj -oz.sik.si KleMeN

2 1