[Cryptography] Should the IV of an encryption operation be input to the key derivation function?

[Natanael]

Den 6 apr. 2017 20:15 skrev "Phillip Hallam-Baker" <phill at hallambaker.com>:

Further to my explorations of HKDF (RFC 3394) I am thinking as follows:

Most cryptographic modes use the same key to encrypt a message. CBC, GCM ,
etc all perform operations on the input data, the key is constant.

When using a public key for exchange, we choose a session key which is
random every time. This each message is guaranteed to be encrypted under a
different key.

If I use KDF with a fixed salt (the norm for most protocols) I get
inter-protocol separation but not separation per message. The IV provides
some protection but I am still handing the attacker a possible advantage.

So what if I was to use the IV of the encrypted data as a part of the salt
in the Key derivation function? Is this a good idea or a bad one?


By comparison, deterministic ECC signatures hashes the message + private
key for the secret nonce. This takes away the need for having a strong RNG
available after key generation.

I see no reason for why reusing the IV with a KDF would break anything if
both the KDF and encryption are using distinct symmetric algorithms (no
cross-protocol exploits), which both allow using a public IV value without
breaking security (that would be most of them).

IV reuse is usually just problematic in the context of the same algorithm +
key (some exceptions may apply, like when when even a public IV absolutely
must be unpredictable ahead of time, in contrast to algorithms that only
requires that it doesn't repeat).

Also, I'm assuming you mean something like encryption key = KDF(root key,
IV), ciphertext = encryption(encryption key, IV, message)? I do think I'd
do it slightly differently by having a derived IV too for the encryption
algorithm, simply by making the KDF output larger and splitting it in two.
I don't think it really changes the security considerations, but it makes
for cleaner separation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170406/bb531c78/attachment.html>