Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Tue, 21 May 2002 01:31:47 +0200

Well, it is not only to add a new packet, but also add to
the user programs a check that if the packet is present in
the signature, the signature block should come from
decrypting a message with one the expected keys.

Clear signed messages should pose no user problems, because
the users generally understands that such the cryptographic
software will not give any confirmation of the origin of the
message.

The problem is that most users when they decrypt a message
that is signed, they will think they can be sure the signer
and the encrypter is the same person/entity.
It would be a major improvement in the OpenPGP specification
to allow applications to ensure that that really is the case.

Have you read the link
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I really think it addresses a real problem.

-- 
Terje Bråten

-----Original Message-----
From: Hal Finney [mailto:[email-masked]]
Sent: 21. mai 2002 00:12
To: [email-masked]; [email-masked]
Subject: Re: secure sign & encrypt

There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal

---

From: "vedaal" <[email-masked]>
Date: Tue, 21 May 2002 08:56:03 -0400

----- Original Message -----
From: "Terje Braaten" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 20, 2002 7:31 PM
Subject: RE: secure sign & encrypt

[...]

> to allow applications to ensure that that really is the case.

[...]

Functionally, that is the case now in Open PGP.

Even though a signed and encrypted message can be separated into a
verifiable free standing signed message, and then
re-encrypted and sent on to someone else,
it 'cannot' {afaik} be re-combined into a signed and encrypted message that
appears the same as a de-novo signed and encrypted message.

The most that can be done with the separation and re-encryption, is to have
a message, that upon decryption, is clearsigned,
or armored signed, and even the armored signed message is clearly of a
different form than a de novo armored signed message;
{a de novo armored signed message always has the message block begin with
the letters 'ow', the separated armored signed
message never does}.

Someone receiving a re-encrypted separated signed message, can instantly
tell upon decryption, that it was an 'intentionally'
re-encrypted message, and not an original.

The only time that this could be a problem, is for very new users, who may
inadvertently get into a habit of clearsigning and then encrypting, instead
of using the one-function 'sign and encrypt' , and as soon as it is pointed
out to them that it is simpler and easier to use 'sign and encrypt' single
function, they will probably do so.

hth,

vedaal

---

From: Derek Atkins <[email-masked]>
Date: 21 May 2002 10:33:31 -0400

sorry, vedaal, but you are incorrect.  With current OpenPGP is _IS_
possible to strip off the encryption from a message and re-encrypt it
to another user, keeping the signature intact.  In fact, back in the
early 90's (and mid-90's when we were first designing the pre-OpenPGP
packets), this was in fact a design goal!

Remember that a signed/encrypted message looks like:

        ESK{PubA, K} ... Enc{K, PreSig{Hash{M}}, Lit{M}, PostSig{Hash{M}}}

Given this format, you can easily replace the K in ESK{} and Enc{}
without destroying the Presig,Literal,PostSig packets.

Now, it may be that the current _implementations_ do not make it easy
for a user to do so, but that is an implementation detail, not a
protocol detail.  The protocol could allow you to do so.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "vedaal" <[email-masked]>
Date: Tue, 21 May 2002 11:36:40 -0400

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2002 10:33 AM
Subject: Re: secure sign & encrypt

> without destroying the Presig,Literal,PostSig packets.

Wouldn't that cause a CRC error, indicating that the message was tampered
with?
Or could a new CRC be calculated and included in the new re-encrypted
message?

Also, could the MDC be utilized to prevent such substitutions, by detecting
alterations of any of the packets?

Thanks,

vedaal

{i don't know,  so am asking}

---

From: Derek Atkins <[email-masked]>
Date: 21 May 2002 12:23:14 -0400

> Or could a new CRC be calculated and included in the new re-encrypted

Which CRC do you mean?  Do you mean the armor CRC?  That's re-created.
Internally, the signature and encryption are completely separable.  If
you sign a message (note: NOT clearsigning), you would get the same
internal structure as you get when you sign and encrypt a message.
The only difference is that in the latter, when you encrypt, you take
the output from the signature transform and encrypt it, rather than
sending it to a file (or to ascii armor).

> alterations of any of the packets?

No, because the MDC could be recreated as well.  The MDC is tied to K
but has no signature associated with it to tie it to the actual
sender.

-derek

---

From: "vedaal" <[email-masked]>
Date: Tue, 21 May 2002 14:20:45 -0400

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2002 12:23 PM
Subject: Re: secure sign & encrypt

> but has no signature associated with it to tie it to the actual

It seems that one thing that is definitely different in a message that is
sent as 'sign and encrypt',
and one that is re-encrypting a signed message, is the time in which it is
being done.

An authentic 'sign and encrypt' message, has the signature and encryption
done within seconds of each other.

If there could be a packet added linking the time of encryption to the time
of signing,
{including elapsed time in seconds [or 0.00x seconds], and therefore not
attackable by trying to re-set the re-encrypting
computer to the time recorded in the original signed message.}
 and that packet tied to an MDC, it might serve as a means of detection of
re-encrypted signed messages.

It should be able to be done without affecting backward compatibility,
and those using earlier implementations, could accomplish the same thing (if
really necessary), by using
[encrypt, sign & encrypt].

--just a thought,

vedaal

---

From: Jon Callas <[email-masked]>
Date: Tue, 21 May 2002 11:31:50 -0700

> alterations of any of the packets?

No. The MDC protects the contents of the symmetric encryption. It does not
protect the ESKs. Nothing protects them, beyond their own encryption.

It would be possible, for example, to make an SMTP server that took a PGP
message with several ESKs in one message, and explode that into N messages,
each with only one ESK. If such a thing existed, the receiver could not
detect it. 

As Derek mentioned, you could even put in utterly bogus MDCs. These could
never be detected as bogus unless you happened to have the key that opened
it.

There are a number of interesting "harrassment attacks" that you can do. For
example, let's suppose I run a server that's an intermediate between Alice
and Bob. I intercept a message Alice's message, and then add in an ESK
that's encrypted to the Lotus Notes/NSA key that Adam Back created into a
PGP key. This is utterly bogus -- I just made up some 128 bit number and
encrypted it to that key. But I insert it in the message and send it on to
Bob. If Bob concludes that Alice is CCing the NSA on messages, then that's a
not unreasonable conclusion to draw. I can just sit back and snicker.

It's important to understand what's in the envelope and what is not in the
envelope. The ESK is like the address on an envelope. It's not in the
envelope. It's outside the envelope and is not protected.

    Jon