How are spoof decryptions prevented?

[Ian Miller]

At 10:31 03/08/99 +0100, Pete Bentley <pete@sorted.org> wrote:
>The LEA can use the public key
>to verify this is the correct session key and can then use the session
>key to decrypt or verify the encrypted text.  
Strictly you need more than merely the session key.  You need the whole of
the PKE plaintext.  e.g. When PGP is using a 1024-bit RSA key, there is
over a 100-bytes of salt in PKE plaintext.  Without the salt, you cannot
validate the PKE encryption.  However the session key decrypting a
comprehensible message should be adequate validation.

More interesting/worrying is the case where the plaintext is random noise.
It may be entirely valid to send a message (most messages even) consisting
largely or entirely of padding to frustration traffic analysis.  If a
message decrypts to "dummy message" followed by lots of random data, how
could anyone possibly determine whether this is genuinely garbage or
contains a second layer of encryption, or that decrypted with a different
key the rest of the message would be comprehensible.

>For something like a one time pad system, then again the only way to
>verify the plaintext and encrypted text match would be with the
>encryption key.  
But you have to take the key-holders' word for what the key is.  If the two
key-holders disagree on what the key is, (e.g. if one is turning Queen's
evidence) then it is simply one person's word against the other.  The data
from the end-point computers may have evidence value, but the interception
itself has none.  This legislation will worthless against OTP.  OTP has
intrinsic complete deniability/unprovability.  


>be impossible for the person to comply with the decryption order at
>all for 'historical' messages.  
This is true of a number of techniques.  Anyone establishing a direct link
to the recipients server, can use Diffie-Hellman or similar to establish a
forward secrecy link.  It is harder to do this with e-mail.  However you
could always include a few one-time keys each message plaintext, to be used
in replies, all such keys to be discarded after use.  

I think that one result of these proposals will be rapid move towards
system that will support forward secret.  If so, some good may come out it.

Ian