From: Jef Poskanzer <jef@ee.lbl.gov>
To: Matt Blaze <mab@research.att.com>
Message Hash: f94d4b34a3a018e4ca2419513dd62bf0480aec24896bf5afee341ca0c04eb527
Message ID: <199407262213.PAA06890@hot.ee.lbl.gov>
Reply To: N/A
UTC Datetime: 1994-07-26 22:13:41 UTC
Raw Date: Tue, 26 Jul 94 15:13:41 PDT
From: Jef Poskanzer <jef@ee.lbl.gov>
Date: Tue, 26 Jul 94 15:13:41 PDT
To: Matt Blaze <mab@research.att.com>
Subject: Re: New Threat on the Horizon: Software Key Escrow
Message-ID: <199407262213.PAA06890@hot.ee.lbl.gov>
MIME-Version: 1.0
Content-Type: text/plain
>The basic idea is that each user gets a unique public key from the
>government, which is used to encrypt the session key. You encrypt the
>session key with this key and send both it and the certified public key
>to the reciever, who verifies the signature to confirm that it really was
>issued by the government. Now the receiver also encrypts the session key
>and compares the result with what you sent, refusing to operate if they
>don't match.
>
>Of course, two parties can cheat by patching their verification routines.
>But it's very hard to interoperate with non-rogues.
I don't see any defense in this description against using someone
else's public key. The feds could still decrypt such messages,
but wouldn't know who was talking. At least not from the envelope.
This could defeat casual mass traffic analysis by agencies who have
the private keys, because they'd have to look inside the messages for
identity cues. It could also defeat *all* traffic analysis by
parties who don't have the private keys. That would make it
preferable to Clipper.
Or does the proposed system also have some authentication component?
---
Jef
Return to July 1994
Return to “Sandy Sandfort <sandfort@crl.com>”