Subject: re: forwarding an encrypted message

From: [email-masked]
Date: Wed, 10 Apr 2002 11:01:47 -0500

From: John Dlugosz

What is the "throw-keyid" switch?

Not all implementations are compelled to support the "your eyes only"
flag.  Someone could run a Perl script on the saved message, for
example, even if he normally uses a GUI that works in the same manner
as NAI's.

"vedaal" <[email-masked]>@mail.imc.org on 04-09-2002 03:26:55 PM

Sent by:  [email-masked]

To:   <[email-masked]>
cc:
Subject:  re: forwarding an encrypted message

- ----- Original Message -----
From: "Simon Josefsson" <[email-masked]>
To: "Marc Mutz" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 09, 2002 3:32 PM
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless

>
> Marc Mutz <[email-masked]> writes:
>
> > What if, in a mail user agent, the user wants to forward an encrypted
> > message? Allow it? Deny it?
> > Re-encrypt or remove encryption?
> >
> > The problem is, of course, that the original sender might not like his
> > encrypted text being sent out in the clear again...
>
> Then the original sender should not send the text to someone who will
> do that.
>
> I don't see how the standard could prevent the user from doing
> this. If it is prevented, then it is only the applications' doing, so
> it wouldn't be difficult to override it.
...
a way to do it, would be to send the original encrypted message using the
throw- keyid switch,

any re-sending of the message would not be able to identify the original
sender,

moreover, the message could also be sent using the option of 'screen
viewing only' so that the plaintext could not be saved,
except tediously by saving a screen shot, or re-typing the message,
both of which can be 'denied' by the original sender, and can be proved by
the forwarder, only by having someone witness the decryption.

hth,

vedaal

---

From: "vedaal" <[email-masked]>
Date: Wed, 10 Apr 2002 13:40:50 -0400

- ----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 10, 2002 12:01 PM
Subject: re: forwarding an encrypted message
...

...

the throw-keyid switch is an option in GnuPG, and also in Disastry's
2.6.31a-multi 5, {but not available in any other PGP implementation}

the throw-keyid option allows for replacing the key id that a message was
encrypted to, with a 'blank' one, {indicating that
the sender wishes the recipients (and the sender as well, if also encrypted
to self by default) to remain anonymous.

the recipient must try 'all secret keys' , and if the appropriate secret
key is on the recipient's keyring, the message will decrypt
upon entry of the correct passphrase.
there is no other indication of which key or keys the message was encrypted
to, and the default encryption to the sender's 
key is also not detectable, even after successful decryption by the
recipient.

there is 'sort of' a way to prevent a signed message from being forwarded,
without changing any requirements, and without
any ways around it:

[1] encrypt, but do not sign,  the original message, 
[2] then, sign and encrypt the first encrypted message

the recipient verifies the signature, and knows that the  unsigned
encrypted message was sent by the reciever and intended
for the recipient.

nothing can prevent the recipient from forwarding the 'content' of the
message,
but unless the recipient wants to decrypt in front of witnesses, there is
no other way to link the plaintext to the sender's signature.

all the best,
vedaal

---

From: David Shaw <[email-masked]>
Date: Wed, 10 Apr 2002 14:12:25 -0400

> What is the "throw-keyid" switch?

"throw-keyid" is what GnuPG calls using the wildcard or speculative
keyid.  Basically it means that a sender can specify the recepient key
id as zero, which tells the receiving program to try all possible
secret keys.  It helps resist traffic analysis as a snooper cannot
easily tell who the message is intended for.  See RFC2440, section 5.1
for more details.  I don't see how this would help with the message
forwarding problem being discussed though.

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies