Son of Clipper (commentary)

[Jim Gillogly <jim@rand.org>]

I didn't want to mix my comments with the recent discussion paper I sent
along, so here they are separately.  Please refer back to my last msg to
see the points I'm bitching about.

It's a depressingly restrictive list of things to require for software
escrow encryption.  I can only conclude that they're not serious.  Clipper
itself fails to meet many of them, including (I think) #1, #2, #5, and #6.
Rumor has it that Clipper does not meet #9 either -- at Crypto '95
somebody in the Key Escrow session said many government Clipper keys are
not escrowed, and somebody in the back spoke up and said he owned such a
chip.  By the way, Moti Yung (noted crypto guy at IBM Yorktown Heights)
presented more breaks in Clipper's protocols like those Matt Blaze found,
and pointed out some aspects of Matt's break that he thinks make it more
important than previously thought.

Other things that bother me about the list:

#1: If it's escrowed, there should be no need to limit the key length unless
    somebody's planning to cheat.

#3: This rules out the possibility of escrowing individual session keys to
    limit the access of LE to sessions they are entitled by law to intercept.

#5: Care to tell us how to create software that can't be patched?
    This is one that's been played in the marketplace and has lost.  The
    battle between copy protectors and crackers has been decided in favor
    of the crackers: legitimate users largely refuse to buy packages that
    are too messy to deal with (e.g. they leave hidden files all over the
    disk, which may interfere with backups or other programs) or that use
    special purpose hardware (e.g. dongles that eat up a printer port).

    This one's a loser, I think.

#6: This is clearly a research issue.  Several speakers (even pro-GAK) at
    Crypto '95 said the policy decisions are being made before the
    research has been done.  The protocols and system specifications are
    key here, and it's not obvious how this criterion can be met.  It's
    not obviously impossible, but it certainly hasn't been solved in Clipper.

#7: One of the Crypto '95 attacks on the Clipper protocol makes use of
    this misfeature of Clipper.  It allows a broadening of the net of
    captured keys so that many more unauthorized messages may be read.

#8: See #3 above -- let's wait on the policy decision until we have a policy
    debate.  A mandated compromise is an oxymoron.  I (for one) would prefer
    to see much more limited keys (like session keys) if Congress decides
    that the right to privacy is not infringed by these technologies.

There's nothing in here that specifically excludes dividing your keys
among multiple escrow agents; I assume this is still an open issue still,
or that it goes without saying (one way or the other).

#3 and #6 make it impossible to prevent LE from reading messages from
before or after their legally authorized window.  This is clearly broken.

Again, this appears to be trying to put all the power in the hands of LE to
the detriment of the people.  It's advertized as a compromise, but I see
nothing gained over Clipper I.  The only differences appear to be that the
escrow agent(s) may be private instead of government, and the algorithms may
be something other than SKIPJACK as long as they are at least 16 bits
weaker as well as being known algorithms.

It also doesn't address the main problem with Clipper I: that it wouldn't
work, since (like Clipper I) it will catch only crooks who are smart enough
to encrypt but stupid enough to encrypt with a system they (should) know LE
can read -- probably a null set.  If, on the other hand, this is made
mandatory for encrypted transmissions, it will create a new and unnecessary
class of criminals, probably including myself (though I won't promise to
break any laws at this point).

This really burns me up.  What do they think they're doing here?  Am I
missing a big piece of it?

	Jim Gillogly
	Hevensday, 14 Halimath S.R. 1995, 22:02