From: Bill Stewart <stewarts@ix.netcom.com>
Date: Mon, 20 Oct 1997 04:17:50 +0800
To: Ian Miller <ietf-open-pgp@imc.org
Subject: Re: Revealing individual messages.
In-Reply-To: <199710180748.IAA00798@server.test.net>
Message-ID: <3.0.3.32.19971019130323.006dbf48@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



At 02:34 PM 10/18/1997 +0100, Ian Miller wrote, to ietf-open-pgp@imc.org
>One thing sadly lacking from all current PGP implementations is the ability
>to reveal the contents of _some_ messages encrypted to you, without handing
>over the secret key.  This is most important as damage limitation when
>ordered by a court of law to reveal certain messages.  [The most
>pathological case is where Mallory has generated those messages himself,
>merely to persuade the courts to force you to hand over your privacy key.]

The easy approach is to decrypt the message, but there's of course
no way for the Court to validate that your decryption was correct.
But if you want more than that, it's not hard to write, either by
finding where in the 7000 pages of PGP source (:-) to add a few
print statements, or by using the APIs when they come out.
Perhaps it's even there today, by setting -debug=42 or whatever.

The decryption needs to show
1) The public key that was used to encrypt the message
2) The PK-encrypted session key, including the random padding
3) The decryption of the PK-encrypted session key, including the random padding,
	(and including the algorithm indicator, if it's encrypted)
3.1) Indication of which bits are the session key  itself, for the slow-witted
4) The decrypted compressed plaintext (optional)
5) The decrypted raw plaintext

And it would be nice to have a tool that also provides a mechanism
to encrypt a random-padded session key to a public key 
to verify the output.  Perhaps Adam Back (et al.)'s 2-line perl code,
with some pretty output formatting.

> Accordingly for RSA encryption at least I propose a
>modification to the DEK plaintext that contains the session key.  Currently
>this is largely random containing over a hundred bytes of nonce
>(for a 1024bit-key).  If part of this nonce was replaced by sender-Id,
>timestamp and similar data, then Alice would at least learn who had sent
>the message (Bob) and when.  They might then have to opportunity to contact
>the Bob to ask for retransmission and warn of the interception.

No way.  This is bad.  You don't want traceability built into PGP.
If the sender _wants_ to be traceable, he can sign the message.
If the sender wants convenient but repudiable identification,
he can put his name and any other information he wants in the plaintext.

Besides, PGP doesn't know who the sender _is_ except by signature;
you can set a default key if you like, but otherwise there's no way
for PGP to decide whether to use the "Bob <marley@wailers.com>" key
in Bob's secret key ring, or the "Louis Freeh <biglouie@fbi.com>" key,
and for that matter PGP will work fine with no secret-key file at all.

If you're concerned about Bad Cops planting forged messages on people, 
this won't help - it's easy for them to forge unsigned information also.
After all, the PGP source code is open, so Bad Cops can add code to
set the timestamp/sender/etc themselves.  Or they can ignore code,
and just set their system clock appropriately.

				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639