[1588] in cryptography@c2.net mail archive
Re: Crypto Keys as Spam
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Tue Sep 23 13:15:49 1997
To: Bill Frantz <frantz@netcom.com>
cc: Charles Platt <cp@panix.com>, cryptography@c2.net
Date: Tue, 23 Sep 1997 12:54:53 -0400
From: Steven Bellovin <smb@research.att.com>
At 7:20 AM -0700 9/23/97, Steven Bellovin wrote:
>Recall that some existing key "recovery" schemes simply have the sess
ion key
>transmitted in-band, encrypted with J. Edgar Hoover's public key. An
yone
>monitoring the session gets the key, and if you aren't monitoring the
>session you don't need the key. After all, there's no requirement
>that you have to record all of your own conversations. Yet.
Note that this kind of protocol creates a single key, which if
compromised, will cause everyone using the protocol to lose
security. I consider it too dangerous for any data that was
more than mildly confidential.
Well, Clipper used it, only worse -- it was a symmetric system, so the
*only* protection for the key was the tamper resistance of the chip...
I'm not trying to be literal in my protocol suggestions on this
topic (why on earth would I *want* to help Big Brother design eavesdropping
gear?), and trying to do a protocol design in real-time is fraught with
peril. But let me sketch a more secure variant on the same scheme,
similar to one designed (I think) by TIS.
Give each user a personal public recovery key R. If you want and/or the
law mandates, embed this public key in a government-signed certificate.
Also assign a public key F for the recovery center of your (or Louis Freeh's)
choice. Now transmit the following message:
F{alice, bob, R{alice, bob, K}}
where alice and bob are the correspondents and K is the session key.
A spook who wants to read the traffic takes that packet and hands it
to the recovery center, along with a warrant signed by Judge F.I. Sa.
The recovery center strips off the outer layer, verifies that one of
the names inside corresponds to the names on the warrant, and then uses
their names to look up the proper R key. This is decrypted in a secure
box that has been fed the proper name. If the inside and outside names
match, K is emitted. If they don't match, email is sent to root@aclu.org
or some such. There are many obvious variants, including ways to
disclose R to an agent (or a spy impersonating an agent) with the
proper warrant.
Risky? Of course it's risky -- that's what the "Risks of Key Recovery"
report was all about. This scheme is safer than the single-key straw
man I mentioned earlier, but any time there are keys floating around loose
you've got trouble. My basic point, though, is the same: the transaction
and storage requirements are proportional to the number of principals
and the number of recovery centers, *not* the number of session keys.
Trying to overload the administrative mechanisms won't work that easily.
And for those who want to overload the per-principal mechanism -- expect
a "user fee" for each recovery key registered. After all, you currently
pay for your driver's license, etc., right? And if the fee discourages
you from using cryptography -- well, that would be a pity...
