[1603] in cryptography@c2.net mail archive
Re: Crypto Keys as Spam
daemon@ATHENA.MIT.EDU (Bill Stewart)
Tue Sep 23 22:34:11 1997
Date: Tue, 23 Sep 1997 18:26:02 -0700
To: cryptography@c2.net
From: Bill Stewart <stewarts@ix.netcom.com>
In-Reply-To: <199709231654.MAA05701@postal.research.att.com>
At 12:54 PM 09/23/1997 -0400, Steven Bellovin wrote:
>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.
TIS's mechanism also made it easy to tell if the escrow bits were correct
and that the escrow key was signed by an official escrow agency.
>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...
Yeah. It's even worse than it appears.
If the Congress were to legislate one specific mechanism and policy,
you could work around it, flood it, or evade it, until Congress changes the
law.
But it's not practical - it'd interfere with too many politically
well-connected
or otherwise important industries to have an inflexible system.
Instead, they'd appoint some executive branch rule-making organization,
whether in Commerce or the FCC or NIST, fronting for the NSA and FBI,
who can change the details of the policy at any time, or for anybody --
more or less the way the export rules have worked but including GAK.
I agree with Steve that the most practical implementations either scale
per principal, per recovery center, or both; a simple approach for the most
common cases is to follow the hierarchical Certificate Agency approach
for public keys, requiring the CA to hold the public key,
and requiring the user to either do encrypt-to-self or equivalent or
perhaps allow encryption to recipients whose keys are signed by CAs.
It doesn't matter whether the GAK-CA is government-run or privately-run;
privately-run allows the government to pretend the cost is lower
because it's not _their_ budget, they get some deniability, and it's
always fun to use FUD to accomplish things when equivalent laws would be
unconstitutional or politically difficult to sustain. On the other boot,
government-run CAs give them the Internet Driver's License control,
unlike private CAs which can issue multiple certificates to people.
For efficiency reasons, "approved" software could use one secret key
to encrypt session keys, with a copy of the secret key encrypted to the
user's public key (and probably signed by it as well.)
In practice, they'd either have to ban Diffie-Hellman or require
extra recovery support.
Thanks!
Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
