[1525] in cryptography@c2.net mail archive
Re: Access to Plaintext: An Obvious Consequence
daemon@ATHENA.MIT.EDU (Bill Stewart)
Thu Sep 18 12:05:32 1997
Date: Wed, 17 Sep 1997 22:39:58 -0700
To: Phil Karn <karn@qualcomm.com>, rah@shipwright.com
From: Bill Stewart <stewarts@ix.netcom.com>
Cc: cryptography@c2.net, karn@qualcomm.com
In-Reply-To: <m0xBCJY-000HQDC@laptop.ka9q.ampr.org>
At 10:06 PM 9/16/97 -0700, Phil Karn wrote:
>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.
Overkill, though of course some of the Clipper I and II proposals pushed it.
For two-way applications, or one-way-plus-acks applications like email,
if both directions use the same session key, or you include both directions'
session keys in the GAK message, it doesn't matter that they're different,
since the Wiretappers can just try both keys and see which works,
and if either side feels like cooperating with the FBI, they win.
The main reason for requiring non-interoperation is to bully people into
using GAKked products, by recruiting the conformists into getting the
non-conformists to use the GAK version. There's a minor secondary value,
in that it's probably easier to detect spoofing by looking for different GAK
fields without going to the effort of decrypting them, but the formats
may not always support that (e.g. RSA("Alice,Bob,12345678",FBI) !=
RSA("Bob,Alice,12345678",FBI) so you may need to decrypt anyway.)
Thanks!
Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
