[1518] in cryptography@c2.net mail archive
Re: Access to Plaintext: An Obvious Consequence
daemon@ATHENA.MIT.EDU (Phil Karn)
Wed Sep 17 18:50:12 1997
Date: Tue, 16 Sep 1997 22:06:12 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
To: rah@shipwright.com
CC: cryptography@c2.net, karn@qualcomm.com
In-reply-to: <v03110769b044bd788d52@[139.167.130.248]> (message from Robert
Hettinga on Tue, 16 Sep 1997 18:49:44 -0400)
>If no encryption product can be sold that can't decrypt everything it
>encrypts, then
>no public key systems can come to market. That would effectively eliminate
>the entire range of encryption products of interest to you.
I don't see how that follows. The FBI doesn't care if *you* can
decrypt whatever you encrypt. THEY want to be able to decrypt whatever
you encrypt. This could be done by having the sending product encrypt
its session key in the FBI's public key, which means anybody with the
FBI's secret key could decrypt it.
It does seem difficult to design a GAK scheme in software that can't
be defeated. The Clipper scheme won't work because you don't have
tamperproof hardware to store the family key and to keep the algorithm
from being hacked.
The only escrow scheme I can think of that's at all suitable for
software implementation is to have each party encrypt the session key
in the FBI's public key and transmit it over the channel. If the
parties compare results, they can detect that the remote party has
bypassed key escrow and refuse to function even though it can't
actully decrypt what the other party sent. Then you'd have to hack
*both* ends to function successfully with escrow disabled.
I expect the FBI to require such a feature. Which is a good thing, as
it can help protect you from being quietly compromised by an unhacked
remote peer even when you've disabled key escrow on your end. Ideally,
your hack should monitor what the peer sends and warn you if
the peer appears to be implementing key escrow.
If the worst happens and something like the Intelligence or National
Security bills become law, I predict a fine time defining just which
encryption programs must implement key escrow in order to be
distributed, and how they must do it. Will the rule be limited to
complete applications? What about an encryption subroutine or a
library? What about "crypto with a hole"? Will it be legal to
distribute source code, as long as it includes escrow? What if the
escrow stuff is surrounded by #ifdefs? Will it be sufficient for it to
default to "on"? Will it be illegal to distribute English instructions
that disable escrow for a particular product? If so, why would this
not violate the First Amendment even if source code is eventually
ruled to not be speech?
Etc, etc, etc. Should be a *lot* of fun...
Phil
