From msuinfo!agate!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!tcmay Thu Jun 2 22:40:54 1994 Newsgroups: sci.crypt Path: msuinfo!agate!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!tcmay From: tcmay@netcom.com (Timothy C. May) Subject: Re: NYT new or obvious flaw in Clipper Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) X-Newsreader: TIN [version 1.2 PL1] References: <2skudi$3vi@hebron.connected.com> Date: Fri, 3 Jun 1994 01:08:43 GMT Lines: 35 Mark Lloyd (mlloyd@hebron.connected.com) wrote: : Today's (6/2/94) New York Times has an article about a flaw in Clipper. : The flaw in it seems like the many obvious ones discussed often in Sci.crypt : and similar to a paper I presented to the Security and Privacy Advisory : Board a year ago. : Is what is being talked about new work? Is it a non-obvious way to : subvert the checksum? Matt Blaze of AT&T discovered a flaw in the LEAF (Law Enforcement Access Field) process that allows a bogus LEAF number to be generated, one which passes the checksum tests but is useless in decrypting the communication. Thus, users could generate ostensibly valid LEAF numbers but still keep their communications secure from the NSA. The NYT article by John Markoff has a nice sidebar illustration which makes the discovery more understandable. Exact details are circulating in a paper which some of my colleagues have seen (I have not). This is just another stumble-bum episode. Few of the "terrorists and drug lords" I know (g) were planning to use the Clipper system, and now the whole process is even more of a useless system. (Fortunately for us.) "Sink Clipper!" is about to become the past tense. --Tim May -- -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From msuinfo!agate!howland.reston.ans.net!swrinde!news.dell.com!tadpole.com!uunet!imsi.com!newshost!perry Thu Jun 2 22:41:21 1994 Path: msuinfo!agate!howland.reston.ans.net!swrinde!news.dell.com!tadpole.com!uunet!imsi.com!newshost!perry From: perry@snark.imsi.com (Perry E. Metzger) Newsgroups: sci.crypt Subject: Re: NYT new or obvious flaw in Clipper Date: 02 Jun 1994 20:27:46 GMT Organization: Partnership for an America Free Drug Lines: 26 Message-ID: References: <2skudi$3vi@hebron.connected.com> Reply-To: perry@imsi.com NNTP-Posting-Host: snark.imsi.com In-reply-to: mlloyd@hebron.connected.com's message of 2 Jun 1994 08:38:26 -0700 In article <2skudi$3vi@hebron.connected.com> mlloyd@hebron.connected.com (Mark Lloyd) writes: >Today's (6/2/94) New York Times has an article about a flaw in Clipper. >The flaw in it seems like the many obvious ones discussed often in Sci.crypt >and similar to a paper I presented to the Security and Privacy Advisory >Board a year ago. >Is what is being talked about new work? Is it a non-obvious way to >subvert the checksum? Well, Matt Blaze has discovered that it turns out that one can just exhaustively generate LEAFs until one finds valid ones -- one in in 2^16 will work. All you do then is pass a forged LEAF to the other Tessera card, and presto -- you can interoperate with Escrowed Encryption, but defeat the escrow. (There are some subtleties with initialization vectors, but they turn out not to matter.) -- Perry Metzger perry@imsi.com -- Are American citizens really so neurotically uptight about deviant sexual behavior that we will allow our entire information infrastructure to be dictated by the existence of pedophiles? -- Bruce Sterling From msuinfo!uwm.edu!spool.mu.edu!darwin.sura.net!osceola.cs.ucf.edu!fang!ulysses!smb Thu Jun 2 22:43:49 1994 Newsgroups: sci.crypt Path: msuinfo!uwm.edu!spool.mu.edu!darwin.sura.net!osceola.cs.ucf.edu!fang!ulysses!smb From: smb@research.att.com (Steven Bellovin) Subject: Matt Blaze's Clipper attack -- details Message-ID: Sender: netnews@ulysses.homer.att.com (Shankar Ishwar) Organization: AT&T Bell Laboratories Date: Thu, 2 Jun 1994 18:56:25 GMT Lines: 52 I spoke with Matt Blaze; he gave me permission to post a summary of his attacks. But the paper is not yet available for ftp. Matt's work was done using a prototype Tessera card, with a SCSI-PCMCIA interface on a Sun 4. That may (or may not) have implications for some of the performance numbers. There are two classes of ways to foil key escrow. The less interesting class of attacks are non-interoperable. That is, two rogue implementations can talk security, but can't talk to a conforming key escrow device. But there's another attack possible, wherein a rogue application talks to a conforming device, but without presenting a valid LEAF. The LEAF contains a 32 bit unit id, an 80-bit session key encrypted with the per-device secret key, and a 16 bit checksum. The whole thing is encrypted with the family key. The checksum field is based on both the session key and the IV. A receiving device will not decrypt unless it's handed a valid LEAF. But it can only base its judgment on the checksum and on its external knowledge of the key and IV; the actual key in the LEAF is encrypted in a way that it cannot read. LEAFs are sent out of band by the application; they're not concealed in the encrypted data stream. Non-interopable applications work by generating a LEAF/IV pair and not transmitting it. (Users cannot control the IV; the Tessera interface (and maybe the Capstone chip) generates it.) The receiving end does the same thing. You don't need an IV for ECB mode, so you have at least some access to Skipjack that way. But that's too slow; at least in the configuration tested, it took ~50 ms to do an ECB encryption. In CBC mode, if you have the wrong IV, the first block of plaintext will be garbled. But the error recovery properties of CBC guarantee that all subsequent blocks will be decrypted correctly. (Derivation is left as an exercise for the reader.) The solution, then, is simple: just pad your messages with an 8-byte garbage header. OFB and CFB modes can be implemented as well. The obvious way is via ECB mode, but that's too slow. It turns out that with a bit of work, you can use CBC mode as a primitive to build OFB and CFB. I'll describe that if anyone's really interested. The more interesting attack on key escrow is a rogue implementation that can interoperate with a conforming one. The checksum is only 16 bits; it's possible to brute-force it. That is, generate random 128-bit strings, and see if your own Tessera card will accept it as a valid LEAF. Again, recall that it knows only the unencrypted key and the IV. On average, you'll find a hit in 2^15 tries; at 50 ms per try, that's 28 minutes. You can speed this up by running in parallel with multiple Tessera cards. --Steve Bellovin