December 2003 - cypherpunks-legacy

Re: more info from talk at MIT yesterday.
by smb＠research.att.com 17 Dec '03

17 Dec '03

> Bill Sommerfeld says: > > They also had a comment that they considered Blaze's findings to b e > > mostly irrelevant, as the only people who would use it would be > > persons who *didn't* trust the escrow system, but *did* trust the > > algorithm... Defense Messaging System is supposedly going to use Skipjack, so I assume it's reasonably secure - and if there *are* NSA-only backdoors in the algorithm, at least they won't be admitting it to your neighbor hood cops and FBI wiretappers, so you'd have to be an *interesting* suspect to get cracked. Not only that, there have been too many spies found in the various intelligence agencies for them to risk such a thing.

1 0

Re: Faster way to deescrow Clipper won't work
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

Perry answered most of my questions with the new information that the checksum is a function of the IV and session key. That still leaves one big one unanswered: Doesn't the Clipper chip at the other end of the message have to compute and send a LEAF too? Otherwise there would be no way for the wiretappers to identify it. And that LEAF will contain the proper session key unless both ends are using the same hack. Also, what does Clipperphone have that the Tessera board doesn't which keeps this hack from working? Is enough known about the workings of the two so that someone could build a computer-based telephone using Tessera that would be compatible with Clipperphone yet use this hack? -- sidney <sidney(a)taurus.apple.com>

1 0

Re: Faster way to deescrow Clipper
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Sidney Markowitz writes: > If that's the case, then 1) How does the second chip find out what the > session key is? That's a separate protocol issue; Clipper doesn't do any key exchange itself, though Capstone does. Unless manufacturers are bullied/bribed into using a standard implementation, everyone will probably roll their own. > 2) Doesn't the second chip also have to generate and send a > LEAF, if for no other reason than to identify itself to the wiretappers, > and if so won't that give away the session key if that chip's device is not > also hacked? If you use the same session key for both directions of the conversation, which most Clipperphones probably will, then yes, it's true. That means you can only have private conversations with other people who also care about privacy, which is somewhat appropriate. On the other hand, a big use of Clipper is traffic analysis, and Matt's method *will* prevent them from getting your Clipper serial number from your conversations, though they'll get the number for the other end if they're not also hacking LEAFs. That can be a big win, especially if the other end is a well-known person, like your local cellphone provider or president(a)whitehouse.gov. However, one danger of doing this for cellphone calls is that they might notice that calls from your cellphone keep having different LEAFs, and suspect that you're a Potential Troublemaker. 3) If all that is needed for this hack is a LEAF with a proper > checksum, why go through the brute force method of generating random LEAFs? > Why not just buy (or steal or whatever) another Clippered device that you > never use for real communication so the wiretappers have no record of who > has that serial number, and get LEAFs from it? For that matter, why can't > you obtain one LEAF from listening to anybody's Clippered transmission and > use it over and over again? The LEAF depends on the IV for the session, which depends on the session key. Therefore, it's probably different for each call; otherwise you *could* just reuse someone else's LEAF. (This should be obvious, but I wasn't thinking about it when I first read Matt's paper, though the "but the IV will be wrong so that won't work" had been a sufficient distraction for many of us when CLipper first came out.) Remember that they don't record Clipper chip keys when you buy your Clipperphone - otherwise stealing one would be effective. They record the chip-unique backdoor keys when they make the chip, so they can tap *any* conversation they hear without needing to keep track of who owns what phone. On the other hand, for cellphones, it's *real* easy to find out who uses a given chip, since the phone call setup protocols tell them what phone it's coming from, and they _can_ look that up with the phone company, so they can easily do that correlation. (If the Clipper chips are socketed, you could always swap them for occasional more-paranoid-but-still-tappable calls, but that would probably just annoy them.) Bill

1 0

Re: News Flash: Clipper Bug?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> > [ discussion of chip operations ] > > Where did you get the information about the internals? > I've seen no references at all. Back when Clipper was first announced, you could call up Mykotronx and ask them for data sheets on the chip. Don't know if they're still giving them out or not.

1 0

Ultra and Coventy
by smb＠research.att.com 17 Dec '03

17 Dec '03

Perry wrote that the British let Coventry be destroyed lest Ultra be revealed. Kahn doesn't believe that. From ``Kahn on Codes'', p. 110: Nor, to debunk another story, did Churchill let Coventry be destroyed because he believed that defensive measures would risk the secret of ULTRA. Critical analyses of documents show that this is pure myth. The footnote cites F.H. Hinsley with E.E. Thomas, C.F.G Ransom, and R.C. Knight, ``British Intelligence in the Second World War: Its Influence on Strategy and Operations'' (London, 1979- ), I:528-48; N.E. Evans, ``Air Intelligence and the Coventry Raid'', Royal United Services Institution Journal (September 1976), 66-73. I don't have access to either of those publications, so I can't assess that further.

3 3

Re: Faster way to deescrow Clipper
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> The defect in this notion that the LEAF is encrypted with the family > key, which is not public knowledge. The mode that this encryption is > performed in is not public knowledge, either. Yeah, that was brain damage on my part. My basic idea was that it is possible, for some chaining methods, to find out where in the LEAF the chipid is by watching what changes when you vary the keys and the chipids used, even if you *don't* have the Family Key or know the encryption mode, but the set of modes and component orders for which that works is more limited than I first thought. There are still some that work, though. Bill

1 0

Re: Faster way to deescrow Clipper
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>From: sidney(a)taurus.apple.com (Sidney Markowitz) > >Could someone please enlighten me on this: It seems from the descriptions >of the hack to fake a LEAF that 1) When two Clipper chips are going to >communicate, one of them generates the session key and sends a LEAF to the >other chip, 2) The second chip recognizes the LEAF as being valid based on >the validity of the checksum, but does not determine the session key from >the LEAF. The session key encoded with the unit key in the Law Enforcement Access Field is not recoverable. The unit key is only contained within the orignating clipper chip, and within the two escrowed key portions. >If that's the case, then 1) How does the second chip find out what the >session key is? An external key exchange in performed. In the case of AT&T TSD 3600s the key is negotiated between them blindly. > 2) Doesn't the second chip also have to generate and send a >LEAF, if for no other reason than to identify itself to the wiretappers, >and if so won't that give away the session key if that chip's device is not >also hacked? FIPS Pub 185 requires that clipper phones adhere to a protocol not contained within the FIPS, and requires transmission of the LEAF. > 3) If all that is needed for this hack is a LEAF with a proper >checksum, why go through the brute force method of generating random LEAFs? >Why not just buy (or steal or whatever) another Clippered device that you >never use for real communication so the wiretappers have no record of who >has that serial number, and get LEAFs from it? For that matter, why can't >you obtain one LEAF from listening to anybody's Clippered transmission and >use it over and over again? Using a constant unit ID even if the session key is not recoverable, still leaves you open to traffic flow analysis. Using a LEAF from another clipper chip still identifies you (or serves to flag interest). It would be a wise to assume that the adversary routinely decodes all LEAFs crossing their purview, recovering unit IDs. (Which would at least flag a lot of counterfeited LEAFS, were ID ranges or (as in IP) prefixes used.)

1 0

Anonymous Remailers
by ghio＠cmu.edu 17 Dec '03

17 Dec '03

Usura(a)vox.hacktic.nl wrote: >>> Has anyone had any experience chaining from a Cypherpunk-style >>> remailer to anon.penet.fi? Can a "::" separator be used >>> successfully, or which format will work? >> >>I think it can be done... > >I know it can be done... Well, some of the remailers will only send to naxxx(a)anon.penet.fi I think remailer(a)chaos.bsu.edu requires this. Jeff Davis <eagle(a)deeptht.armory.com> wrote: > Today I used the catalyst(a)netcom.com remailer to send an anonymous > contribution to a list. They're raising hell about anonymity in their > list, but that's beside the point. The message also showed up on a > seperate beta test list. I assume this was done manually by > <mcstout(a)netcom.com> bouncing the message to the other list, since he > is the sigular person on the planet subscribed to both lists. mcstout > has been a quite vocal detractor of my catalyst contributions to the > other list. I thus strongly suspect manual sabotage. There was no > flaw in the Request-Remailing-To: adress. > > Could someone please confirm that this was not a quirck of the remailer? Try checking the headers to see what site it came from.

1 0

Re: Faster way to deescrow Clipper
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>From: "Perry E. Metzger" <perry(a)imsi.com> > >Mike Ingle says: > >An interesting idea. > >> The LEAF would look good unless you tried to decrypt the >> session key. The wrong-IV problem would remain. The NSA should have >> designed the Clipper so that, if the IV was wrong, the chips would not >> accept the LEAF. > >That can't be done, I'm afraid. Its way to difficult to distinguish a >bad IV from line noise nuking the first block of your CBC >conversation. I used to work on NSA cryptographic equipment. One of characteristic of a system designed to use crypto is the ability to detect crypto sync. If you have access to the control program (which you would if faking LEAFS), you would tend to throw out the first block. The difficulty is that the DE (distant end) ain't necessarily smart enough to do so (assuming it has not been modified), and is more than likely looking for a passed data value (typically a sync symbol) to determine the state of crypto synchronization. Were the system consuming data from the enciphered link properly prepped, it is possible that it would ignore garbage (Assuming the damaged decrypted first block did not contain the sync), while awaiting a synchronization indicator. Most duplex crypto systems use some variant of End Around Prep (EAP), where the receive data path is used to determine whether crypto synch is acheived by looking for a constant mark or space, or idle character. When the receiver does not provide the proper value the transmit side is knocked down, the DE receive notices and restarts its transmit. A data value is passed through the loop to tell the system to go to operate mode. Such functions are generally predicated on having crypto - and the data system for which it provides a link, separate. The point being that a communications system that you can't modify both ends of may not be able to accept a garbled first block. Not to mention that OFB is probably a lot more prevalent for voice applications.

2 1

Re: LEAF forgery
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wrote about a possible trapdoor in Skipjack to which Perry replied: >Your belief is without evidence. It is a supposition. I'd say the NSA >has a lot to lose by putting holes in Skipjack. How true, yet the NSA also had a lot to lose by putting out a flawed backdoor in Skipjack which essentially negates much of this features (LEAF) value. They did so none the less. In addition, I remember the comments of Stuart Baker; the audacity was typical of an organization which would put in just such a hole and smugly disbelieve that anyone would find out. In addition, it is possible that the agency is not alarmed about their LEAF problems because they don't need to use it. Of course, even if the whole algorithm was compromised I don't think they would show alarm outwardly. The possibilty is still there. Since one does not know the Skipjack design, a belief that it does not contain a trapdoor is without evidence and also a supposition. My contention is that the NSA is cocky enough to disregard the consequences of putting holes in Skipjack. >None the less, I wouldn't use Skipjack, because I don't trust things I >don't know the design of. Me neither, and randomly generating new LEAF fields would not give me comfort as to the security of my transmissions. Which is the main point here in my mind. Scott G. Morham !The First, VACCINIA(a)uncvx1.oit.unc.edu! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLe92xz2paOMjHHAhAQHaUwP/T+Di/N7ej8pfW7jKJJHmV8CTfJaYkYgt ejB2M+QTs23i+6AdT6yiSfs+cGXz19F/eHiNtvemJyYujnyXP8EjxeqkhCIjtu+/ ZkF9dBWSC6V1Xj7MycPZbG8lgv7EY57nnVDU7smv42xbRx9Co9qYF9zRdhe0WRZc Hdzm4YP+8Bw= =T1Tz -----END PGP SIGNATURE-----

2 1