From: "L. Detweiler" <ld231782@longs.lance.colostate.edu>

Now, two Clipper chips will *not* work in conjuction with each other unless each is fed a valid LEEF from the other. However, since the chip does not accomplish this function (the communication, that is; it does *create* the field), and it is handled outside the chip, there is no guarantee that the system designer does not, for example, encrypt the LEEF in the communications transit, thereby completely sabotaging the `exploitative' tappability of the chip.

Hence there is a *very* real possibility that this scheme, or something similar, could be used to gain Skipjack-level encryption without any key escrow complications. I suspect the NSA is *extremely* worried about this. They probably require that the chip purchaser promise to use Clipper in a way that guarantees the LEEF is accessable (plaintext). They may even create a contractual obligation wherein the surrounding device (telephone or whatever) cannot be approved for sale until it passes an NSA endorsed tapping test. (what fun!) I consider this all very plausible and probable. (This would be a neat trick -- use the chip itself to encrypt LEEF fields -- hah! twist an insecure chip into a secure one, and spit in the face of the NSA!)

Having read the chip spec for the MYK-78 carefully, being a chip/hardware weenie type, having military experience in cryptographic systems, and having exposure to Type I chips (which have a lot of similarity to clipper) there is a fundamental architecture feature of the MYK-78 that can be exploited. The MYK-78 allows multiple cryptographic contexts (encryption or decryption sessions) to be processed at the same time. This is intended to allow a chip with a single instantiation of the cryptographic algorithm to be used for full duplex communications. It requires all simultaneous encryption/decryption sessions to use the same session key although multiple cryptographic vectors (from different initial vectors) may be used. The MYK-78 is fast enough (bandwidth wise) to allow 20-30 duplex vocoder conversations, and could be used in a secure phone bridge using a single clipper chip. The undocumented or classified protocol requires that LEEFs be used for each session, extracted for transmission and input for reception. The chip requires that for every initial vector generated/requested that the included Law Enforcement Exploitation Field (LEEF or 'greened' LEAF) be subsequently input to enable decryption. The LEEF is output when the IV is read, the IV is part of the LEEF. (You can see that to use a single MYK-78 for multiple duplex conversations requires care in assuring that the distant end supplies its IV.) Cryptographic context for multiple sessions (send and receive sides for a single duplex path) is save through the use of save and restore context commands. To get around sending the LEEF we instead generate an IV, followed immediately by a save crypto context command (which produces the IV without the LEEF). The feed the IV (actually the LEEF to our own chip to enable decryption. We transmit the IV(sans LEEF) through separate protocol to the distant end. We receive the distant ends LEEFless IV and use it with the restore crypto context command to initialize the decryption session. This allows both ends to operate without actually transmitting a LEEF. Once decryption is enabled cryptographic resyncronization can be limited to exchange of LEEFless IVs. Securely exchanging IVs is not without difficulty. The clipper chip can't be used without establishing secure communications. Clipper chip modes can't be changed without requiring IV (and LEEF) introduction for other than ECB mode. One possibility is to use the chip in ECB mode with external XOR and feedback management to support a feedback mode. Likewise you could through the use of save/restore crypto context commands and by accepting the necessity for cryptographic restarts, switch the chip to ECB mode and encrypt the IV, say in a special key, for transmission to the distant end. A lot of dancing, but no one is allowed to cut in. --

About the only company ready for Clipper chips is AT&T, and I think they are using Diffie Hellman key exchange currently with some proprietary algorithms (they have a license on Public Key directly from PKP already) in their secure phones. I suspect any companies that come out with new phone encryption equipment based on Clipper, if any are insane enough to exist, will try to be compatible with the AT&T `standard' (ug). As far as I know AT&T has not published their own key exchange standard used by the phones, however. That is, it is proprietary, and might even be protected by patents of their own! This is a rare occasion where incompatibility is something to beam about!

From: rjc@gnu.ai.mit.edu (Ray)

"Cypherpunks Hack Hardware"

It seems logical that when the ClipperPhones come out, they will have some kind of vocoder chip in them. (I doubt the (co)decoding will be implemented on the Clipper chip itself) If so, cypherpunks can take advantage of this situation.

Not having seen a clipperphone (there are none currently available), one wonders if it is possible to play the above described trick with the clipper chip and implement your own communications protocol, capturing program control of whatever processor is used. This gives you skipjack security without big brother being inside. A mode switch could include compatiblility with the Escrowed Encryption Standard (EES).

From: "George A. Gleason" <gg@well.sf.ca.us>

Re your suggestion of a cypherpunk daughterboard to substitute for Clipper in "secure" phones etc.:

I have a sneaky suspicion that AT&T won't be quite so cooperative. They constantly do things in such a way as to make it darn hard to do anything with their products except exactly what they intended to do. It might be worth a try though... OTOH anything that creates more demand for AT&T phones is a not-good thing in my view... we need an entirely competing product, and preferably cheaper than an AT&T clipperphone + daughterboard, for obvious competitive reasons.

AT&T uses a proprietary vocoder known as ACELP, which will prevent knock off products without licensing. There are only a limited number of ways to prevent you from modifying their hardware. 1) Built In Test (BIT) features. The processor operating the phone could perform system level integrity checks and could refuse to work if the code space doesn't check out, say for valid memory contents being unmodified, or unused memory space not showing up blank. This could be defeated with access to instruction and data streams. 2) With a high enough level of integration no modification may be possible. (no visability or ability to modify instructions for operating the clipper chip) 3) Refuse to sell you the phones. Seems silly, but they already have rules on who they can sell to (U.S. citizens, corporations), under State Department rules. It seems probable they will do their own distributing and large customer could always be denied sales upon request of virtually any of the components of the U.S. government. 4) Tamperproof packaging of the phone (I don't think they'd get UL approval for self destruct devices), say erasing the vocoder algorithm. Sufficient numbers of false zeroizing should defeat this say, organizing a couple hundred customers to swamp the system. You would think a phone would be vulnerable to false zeroizing from throwing it in your briefcase. 5) Refuse to do maintenance and/or void the warranty. With a sufficient level of integration the phones become throw-aways upon failure. This doesn't affect organized crime. 6) legal barriers, largely ineffective (making it a federal crime to tamper with a clipperphone is a joke). Outlawing nonrecognizable encryption schemes (this could be spoofed, through the use of canned LEEFs with session keys you never intend to use, but allows some useful intelligence (the serial number) to leak. A single stolen and subsequently destroyed phone could supply the LEEF, but still serves as a red flag. The ability to not transmit the LEEF suggests the ability to recognize one. Intercepting and storing several thousand (over time) for use randomly as spoofed headers would hamper detection. This is all predicated on the assumption that at least NSA will test suspected crypto streams for clipper, and routinely do traffic analysis. You could imagine modifying the phone totally nondestructively, through the use of chip clips or whatever. --

From: karn@qualcomm.com (Phil Karn)

Damn. Now I remember one of the points I meant to make in my NIST comments, but forgot: if the LEEF is added periodically to the ciphertext stream, that implies that the ciphertext data rate must be greater than the plaintext rate.

There is no evidence of anything at the chip level requiring periodic LEEF extraction. This would almost undoubtedly be handled at the communications protocol level. One would guess that the feds would be happy to have the LEEF occur every time you require crypto sync. Byte counts could be used to verify all this. --- All of this has to be apparent to at least the NSA, and I'm sure that no disreputable manufacturer will get to play with the clipper chips and build a product that doesn't adhere to EES. Having seen the certification process for implementations of Type I chips, product certification seems likely. Blackmarket demand can be generated from two sources: persons seeking more absolute privacy and criminals seeking secure communications. I am not at all bothered by the privacy aspect, but would be bothered by supplying or modifying phones for criminals, depending on the crime. It seems unlikely that there is any enforceable method to prevent modification of clipperphones, although discovery of a safe modification process could consume a large number of phones if countermeasures are included. All this is very sensistive to economy of scale. The more phone there are out there, the more blackmarket demand for modified phones and the easier it would be to avoid detection. The question is whether given the potential black market for modified clipperphones, whether skipjack is indeed secure against its creator. (sounds paranoid, I know)