Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Wed, 22 May 2002 12:51:36 +0200

vedaal <[email-masked]> wrote:
> 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.}

I do not understand how you intend this packet to be added.
If it is a signature packet, would not the changes to be done
be about the same as if we added an 'encrypted to' packet?
If it is not a signature packet, I do not understand what would
keep the attacker from making a fake timestamp when re-encrypting the
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].

This is also one of the solutions suggested in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
to use encrypt, sign, encrypt instead of just sign & encrypt.
It is also possible to use sign, encrypt, sign.

But I think that adds an computational overhead when processing the
encryption/decryption that would be avoided by adding an extra packet
to the signature.

-- 
Terje Bråten

---

From: "vedaal" <[email-masked]>
Date: Wed, 22 May 2002 09:00:32 -0400

----- Original Message -----
From: "Terje Braaten" <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Sent: Wednesday, May 22, 2002 6:51 AM
Subject: RE: secure sign & encrypt

[...]
> be about the same as if we added an 'encrypted to' packet?

Yes,     it could be done your way too, with about the same amount of
change.

I thought that a packet that simply records the elapsed time in fractions of
a second, between signing and encrypting,
could be added without affecting the signature or encryption packets, and
might be easier to implement without affecting
backward compatiblity.

[...]

> keep the attacker from making a fake timestamp when re-encrypting the

It would be an 'record of actual elapsed time' packet,  measured from the
time the program calls for the time of signing,
to the time it calls for encrypting.  It would not be 'calculated' by
measuring the recorded (old) timestamp of the signature,
and then re-setting the attacker's computer to the same time and measuring
the fractions of seconds till the encryption.

{ i do not yet know how to read and write code :(  , so it is only my
opinion of what seems plausibly 'do-able' ,
it may be that it has flaws that experienced programmers can instantly see,
if so, i apologize in advance}

--vedaal

---

From: Derek Atkins <[email-masked]>
Date: 22 May 2002 10:09:17 -0400

How is the receiver supposed to know what the delta-t is?
How do you deal with different machines of different speeds?
What if the sender is a PalmPilot and the receiver is a Pentium-4 3GHz?
There is absolutely no consistency in the time.

Worse, an attacker who wants to re-send the message already knows what
the original delta-t is, and can add it to any new packets they
create.

Even putting a timestamp into the ESK to enforce "ESK time == Sig
Time" doesn't help you, because there is no way to verify the
timestamp on other ESKs (to see if they've been added).  All you know
is that "This message was encrypted by someone who was able to see the
original" (which could be the sender, or could be one of the
"original" receipients.

No, the best way around this problem is the USER INTERFACE and
EDUCATION.  If you receive a signed message that looks like:

  --- begin message ---
  To: peter, paul, mary
  Subject: Hi
  Date: <now>

  I QUIT!  Have a nice day!
  --- begin signature ---
  <stuff>
  --- end signature ---

(Or think of the same type of message but signed and encrypted)..

Notice how the original recipients are part of the signed message?  If
this gets forwarded to another person, they would know that they were
not an intended recipient.  You cannot change that without
invalidating the signature.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available