vedaal <vedaal(_at_)hotmail(_dot_)com> 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