Xref: cantaloupe.srv.cs.cmu.edu sci.crypt:15284 comp.security.misc:3400 alt.security:9966 comp.org.eff.talk:16904 alt.privacy:6585
Newsgroups: sci.crypt,comp.security.misc,alt.security,comp.org.eff.talk,alt.privacy,alt.privacy.clipper
Path: cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!fs7.ece.cmu.edu!europa.eng.gtefsd.com!emory!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!att!ulysses!ulysses!smb
From: smb@research.att.com (Steven Bellovin)
Subject: Clipper -- some new thoughts
Message-ID: <1993Apr17.175656.23656@ulysses.att.com>
Date: Sat, 17 Apr 1993 17:56:56 GMT
Organization: AT&T Bell Laboratories
Followup-To: sci.crypt
Lines: 55

I'd *desparately* prefer it if we didn't rehash the same arguments
that went on ad infinitum last time.  That's especially true for
sci.crypt.  For that matter, I've created alt.privacy.clipper, since
the traffic is appearing in *many* different groups right now.

I'm going to focus here on some technical aspects of the plan, hence my
followup to sci.crypt.  Frankly, if you're not an absolutist, your
feelings may turn on some of these issues.  For example -- with an
80-bit key, simply splitting it into two 40-bit pieces is much less
acceptable than other schemes, because it means that if just one
repository is, shall we say, overly pliable, a would-be eavesdropper
would need to recover just 40 more bits of key.  I need not point out
in this newsgroup that that's pretty easy to do by exhaustive search.
A slightly more complex scheme -- XOR-ing the key with a random number,
and then with its complement -- would produce two 80-bit subkeys,
neither of which is useful alone.  That variant is much more resistant
to attack.  Clearly, one can get even more sophisticated, to protect
the subkeys even more.

Other thoughts...  Some people have noted the size and complexity of
the databases necessary.  But the id strings the phones emit could be
their back door key, double-encrypted with the escrow repositories'
public keys.  For that matter, they could do that only with session
keys, and have no back door at all.  In that case, the FBI would have
to bring every intercept to the repositories to be decrypted.  This
would answer many of the objections along the lines of ``how do you
make sure they stop''.

We can even combine that with a variant of the digital telephony back
door -- have the switch do the tap, but with a digitally-signed record
of the time, phone number, etc, of the call.  That provides proof to
the escrow agents that the tap was done in compliance with the terms of
the warrant.

I can suggest other variations, too.  Suppose each Clipper chip had 100
public key pairs.  Each would be used ~10 times, after which you'd need
more keying material.  (Not a bad idea in any event.)  This could be
used to enforce time limits, or rather, usage limits, on each warrant;
the keys the repository agents would deliver wouldn't last for very
long.

I suspect that the cryptographic algorithm itself is secure.  Apart from
the obvious -- why push a weak algorithm when you've already got the
back door? -- I think that the government is still genuinely concerned
about foreign espionage, especially aimed at commercial targets.  This
scheme lets the spooks have their cake and eat it, too.  (I've heard
rumors, over the years, that some factions within NSA were unhappy with
DES because it was too good.  Not that they couldn't crack it, but it
was much too expensive to do so as easily as they'd want.)  They're keeping
the details secret so that others don't build their own implementations
without the back door.

The cryptographic protocol, though, is another matter.  I see no valid
reasons for keeping it secret, and -- as I hope I've shown above -- there
are a lot of ways to do things that aren't (quite) as bad.
