Re: Signatures and encryption headers



In this situation,

while header need only for decryption,
and payload had been signed before encryption --
you don't need to sign header values, I think.

If someone replaces any field, message will be decrypted
incorrectly, and payload signature check will fail.

There only resend attack possible - with injection whole
old valid messages (prev. saved).

But, if recipient care about resend/reroute attack blocking
on the level after decryption, you do not worry about this.

Oleg


Fabrice wrote:
On Nov 4, 3:20 pm, Oleg Khovayko <"[my_last_name]"@gmail.com> wrote:
As minimum, you need add into signed area some timestamp
and sequence number, for resist to "resend attack".

In this attack, Mallory sends to recipient old _valid_ message,
from huge collection, accumulated during long time of listening.

There is no notion of time in the encryption header. If any notion of
time is required it would be included in the payload, encrypted and
signed. The encryption header only includes the information required
to decrypt the payload. Anything else would be part of the payload
(and be encrypted if the payload is).

-- Fabrice

Oleg

Fabrice wrote:
Hi,
Let say I have a payload of data I want to encrypt and sign.
The system support various formats for encryption, such as different
cipher, chaining mode, usage of session key etc...
So I create an encryption header that basically include:
- The payload size
- Which cipher and chaining mode are used.
- An encrypted session key
- An IV
- A key index that indicate the recipient which key to uses to decrypt
- Some parameters used to derive the real key used
- etc...
So the clear payload is signed, then its encrypted.
The encryption header, payload and signatures are sent to the
recipient.
Now the question is: should this header be signed too ? Or is it
unnecessary ?
I say its unnecessary as long as the recipient validate properly the
parameters. Whatever an attacker might change in the encryption
header, will change the decrypted payload and will cause the signature
check to fail.
Other people might say that the recipient should not do any
computation with any data that has not been signed. That it might be
possible to exploit the header to cause a fault in the recipient that
might cause him to do something bad...
Whats your take on this ? Should the encryption header be signed or
not ?
Thanks
.



Relevant Pages

  • Re: wireless: recap of current issues (other issues / fake ethernet)
    ... > in the control structure decide whether the 802.11 or the 802.3 header is ... > the front of the frame via hard_header_len. ... This amount also varies with different encryption modes. ... - LLC+SNAP header on payload ...
    (Linux-Kernel)
  • Re: Hash question ...
    ... header of the file. ... When a user enters an incorrect passphrase, ... if I generate an encryption key with the ... could I safely store the SHA of the passphrase ...
    (sci.crypt)
  • A Paranoid Encryption Mode
    ... header field sent in the clear, ... the random session key being used to leak key bits by tampering. ... OAEP and the various attempts at integrity-aware encryption modes. ... maximum-period shift register in Galois configuration that is stepped ...
    (sci.crypt)
  • Re: Signatures and encryption headers
    ... payload and signatures are sent to the ... cryptographicattacks. ... finalize the hash and check the signature. ... But then this mean you would be using the encryption header before you ...
    (sci.crypt)
  • A Paranoid Encryption Mode
    ... > the random session key being used to leak key bits by tampering. ... I don't find the idea of simply encrypting the header ... > OAEP and the various attempts at integrity-aware encryption modes. ... it possible for an attacker to perform some sort of precomputations ...
    (sci.crypt)