[280] in cryptography@c2.net mail archive
Re: GAK in domestic crypto products
daemon@ATHENA.MIT.EDU (David Wagner)
Fri Feb 21 21:36:51 1997
To: cryptography@c2.net
From: daw@cs.berkeley.edu (David Wagner)
Date: 21 Feb 1997 17:41:05 -0800
In article <2.2.32.19970221202425.006c7178@remote.transarc.com>,
Lyle Seaman <lws@ms.com> wrote:
> I think that all this is saying is that if a domestic entity (person,
> server, whatever) is communicating with a foreign entity (person, client,
> whatever), then the keys which are obtained must be able to decrypt data
> flowing in each direction.
>
> I don't see how it makes it terribly difficult to interoperate.
Oh, but it does, for offline store-and-forward communications. (Think email.)
In more detail, you must make sure that recipients who can support non-GAKed
crypto will receive email encrypted with non-GAKed keys; how does the domestic
sender know what security level the recipient can support?
(You'll end up re-designing the concept of autocerts, and you'll have to make
sure that those autocerts get distributed *securely* by the key distribution
infrastructure along with each public key. Now try to figure out how to do
this for PGP -- heh, good luck. Raph Levien has talked about this a number
of times.)
The S/MIME folks, in fact, ran into this problem headlong, as Raph reported
some months back. I don't know whether they've solved it satisfactorily by
now, but it could represent a weak underbelly; the problem certainly presents
non-trivial design issues.
Matt Blaze likes to point out that GAK adds lots of untested complexity to
our cryptosystems; and complexity is directly at odds with robust security.
He's right, and this is yet another example of that general principle.
