Subject: Details of flaw in Clipper

From: [email-masked] (Sidney Markowitz)
Date: Fri, 3 Jun 1994 20:14:29 -0700

I have seen lots of discussion about the New York Times report on Matt Blaze's
discovery of a flaw in Clipper's key escrow system, with more confusion than
anything else. Here is the best article that I have seen on the net explaining
exactly what Dr. Blaze has found. There's also confusion about the
implications. My understanding is that this method might allow someone with a
Clipper chip device to have a secure communication with another person with a
Clipper device that could not be decrypted by law enforcement *and* it does
not require the cooperation of the second person.  That last part is what
makes this significant, since two people can agree to just encrypt their
messages with, say PGP, if they want to be secure from law enforcement
decryption. But if Blaze's method is practical, the widespread use of Clipper
would make it harder on law enforcement by making it easier than it is now for
someone to have secure communication with people without having to plan with
them to do so.

 -- sidney markowitz <[email-masked]>

[begin quote of Message-ID: <[email-masked]>
 crossposted to sci.crypt, talk.politics.crypto, alt.policy.clipper]

   [Run in RISKS with permission of "Perry E. Metzger" <[email-masked]>.  PGN]

Many people have misconceptions about what Matt did.

Based on his paper (no, you can't have a copy since he told me not to
distribute it; I'm sure he'll release it when its ready for prime time) and
discussions with him, the trick is this.

[The Escrowed Encryption Standard is abbreviated as EES.]

The LEAF acts much as an key to tell the EES unit that it should
function. It contains three elements:

1) the 32 bit unit id of the EES unit generating the LEAF
2) the 80 bit session key, encrypted in the escrowed key for that unit.
3) a 16 bit checksum based on the unencrypted session key and the
   initialization vector (IV) for the session.

All three components are concatenated to form a 128 bit unit, which is
encrypted in the family key in order to produce the LEAF, reportedly using a
unique mode of Skipjack.

The remote unit takes in the LEAF, decrypts it with the family key, and checks
the cleartext session key and IV to see if they produce the proper 16 bit
checksum. If so, it accepts the LEAF and functions properly. Note that the
encrypted key inside the LEAF is useless to the remote EES since it doesn't
have the other EES's escrowed key. It has to rely on the cleartext session key
and IV alone to check that the checksum looks right.

Sadly for the NSA, the checksum is only 16 bits long. Given a session key and
initialization vector, I can fairly quickly generate a large number of fake
LEAFs (chosen at random) and find one that a captive EES unit will accept as
being the right LEAF for a given session key/IV. The contents of the LEAF will
be garbage, but the remote unit will not know that, and will happily go along
with using it. I needn't know the family key, or even the checksum algorithm.

The point here is, of course, that I can freely interoperate with non-rogue
EES units -- I can communicate with non-subverted units without revealing my
privates hidden beneath the LEAF. (sorry for the pun.) [*]

By the way, Matt had to figure out the components of the checksum on his own
-- the mechanism for calculating it and where it came from were not
documented.

BTW, for those who have asked, in case the preceding didn't make it clear,
can't you just reuse an old LEAF or a stolen LEAF because the session key/IV
won't correspond and the checksum won't be right -- you have to generate and
test.

Perry Metzger		[email-masked]

[end quoted message]

     [*] [Turning over a new LEAF is better than if you LEAF 
         well enough alone, he suggested FIGuratively.  PGN]