Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless

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

From: John Dlugosz

>> I'm not quite that extreme, but I don't sign anything that I wouldn't
sign
if it were on paper, not on bits.

I'm a bit more mellow.  When talking to someone on the phone, you can
authenticate who you are talking to, from the voice.  In hand-written
letters, you can see the handwriting.  Electronic text has =no=
personalization to it, so the signature takes the place.

>> OpenPGP specifies that the signature goes inside the envelope. The
reason

I understand the reasons why encrypt-then-sign is better.  But I think it
could be even better yet.  Mathematically combining the two operations into
one, or, to reuse existing primitives, jump through hoops.  For example,
take a nonce and logically append both half its plaintext and ciphertext to
the original plaintext that will be signed.  Now, you can't verify the
signature without also being able to verify that the included nonce
decrypts, as well.

Hmm, a simpler way would be to use a keyed hash to make the digest, with
the key encrypted "to" the recipient.  Yea, I like that.  Let me further
refine... A subpacket contains the HMAC key and a block of random numbers
the same size as the hash (e.g. 160 bits), encrypted to the recipient.  The
recipient decrypts the key, repeats the hash, and then XOR's in the random
number.  The result is sent to the basic signature algorithm.  Now, if he
chooses to reveal the contents of this inner packet without providing the
means to decrypt it himself, then it's trivial to forge because you can
adjust the random number to make the hash match that of a tampered message.
Result, you can't verify the signature without being able to decode the
inner envelope.  The inner envelope is signed by itself, and would contain
a plain hash of the main message, to tie it together.

Jon Callas <[email-masked]> on 04-09-2002 04:27:04 PM

To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked], [email-masked]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless

At 3:33 PM -0500 4/9/02, [email-masked] wrote:

>But I think PGP uses "sign, then encrypt" which means software could
>decrypt but leave the signature intact.  As I recall, this was thought to
>be a non-problem with respect to re-targeting, because you can put the
>recipient's name in the message at the application level.  e.g. "Dear
Sue,"
>is part of the message, so it can't be mistaken as a message to Joan.  But
>that doesn't handle the issue of private information in the message.  It's
>possible for Sue to reveal the signed message to someone else, who can
>verify the signature, without needing Sue's key.  I would prefer if that
>were impossible--without Sue's key, the message can't be authenticated
>either.

OpenPGP specifies that the signature goes inside the envelope. The reason
for this is that if the signature is outside the envelope, then the
attacker knows both the source and destination of the message. In short, it
provides cryptographically enhanced traffic analysis.

Yes, you're right, someone can decrypt a signed message and then send on
the signed, decrypted message. They can also take a screenshot of the
screen and send the image on to someone else. I know many people who do not
sign messages for this very reason. We added a non-signature integrity
check to OpenPGP messages so you'd have some way of knowing you got the
message intact without requiring the sender to sign it.

There are security risks to signing messages. A good friend of mine is of
the opinion that you should never sign anything that you aren't willing to
forward on to City Hall for inclusion in the public record. He never signed
anyone ele's key for this reason, let alone a message. I'll add that this
guy was an VP at an investment bank, not a cypherpunk with outlaw
fantasies.

I'm not quite that extreme, but I don't sign anything that I wouldn't sign
if it were on paper, not on bits.

Mathematics cannot solve real-world security problems. If you're confessing
secrets to someone who gossips, you have security problems. If you send
signed, encrypted messages to someone who will decrypt them and send them
(or send a screenshot of your messagae) on, then you have the same security
problem.

A trusted channel to an untrustworthy person is not secure. And to
paraphrase Laotse, you cannot create trust with cryptography, no matter how
much cryptography you use.

     Jon

---

From: [email-masked]
Date: Wed, 10 Apr 2002 14:54:17 -0500

From: John Dlugosz

Here's another way to make sure that someone doesn't strip away the
encryption envelope but leave the signature and forward the signed
document:  By analogy with the "Dear Sue" content to prevent authenticated
message re-use, you can do this on the application level.

Include in the signed text a statement that the intended recipient still
wants to keep secret.  now he will have to excerpt the main message of
interest (and lose your signature) or act against his own interest, which
may be different from the interest context of the main message.

--John

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 11 Apr 2002 18:23:34 +1200 (NZST)

Sam Roberts <[email-masked]> writes:

>S/MIME only uses the signed and enveloped types from CMS, but RFC2630
>specifies authenticated as well. Its not well described there, but it is a
>way of "signing" something using a key agreement algorithm, such that the
>signature can ONLY be verified by using the sender or the receiver's
>private key.

Hmm, are you sure you're not interpreting a bit too much into this
data type?  The intent is to allow MAC'ing of data, and to do that you
need to share a key with the other side, which is why you need a key
exchange to precede it.  One of those happens to be X9.42.  There are
two issues with this:

1. The only implementation which is known to support X9.42 in any
   useful manner is the SFL.
2. There don't seem to be any implementations which support
   authenticatedData, or at least that was the case when I asked on 
   the S/MIME list a while back for someone to do some interop testing 
   with.

(Oh, and the obvious third point: If you're doing a PKC operation for
 the key exchange anyway, you may as well just sign the thing directly.
 At best, you can claim that this gives you a signature capability
 using an encryption-only key).

I've always seen the only real use for this data type as password-
based integrity protection for data you're carrying around, using in
conjunction with passwordRecipientInfo.

>What this gives you is repudiation. If I authenticate something to
>you, you know I authenticated it. But if you forward it somebody
>else, they can't verify the signature, they have no way of knowing
>for sure that I authenticated it, and I can deny it. Even if the
>recipients private key is compromised, they still can't prove
>that *I* authenticated it, since either one of us can create the
>"signature", all they know is one of us made the authenticated data.

Well, only if you use some of the obscure X9.42 options which don't
identify sender and receiver.  The default is to list both, although
there are a pile of optional parameters and with only one known
implementation who knows what will happen in real life.

Peter.