1
$\begingroup$

Imagine a channel where the initial secret for deriving of the actual key is established with ECDH.

First, that shared secret is used to derive a temporary key with some default parameters (salt, iterations) embedded into the software.

Then this channel is used to exchange random parameters specific to each direction (Alice sends to Bob parameters Bob must use to derive the key Bob must use to encrypt messages to Alice) and in response Bob sends such parameters [salt and iterations] Alice must use for HKDF to derive the key to encrypt messages for Bob.

Eventually, they exchanged these parameters and derive their own key per direction (Alice to Bob and Bob to Alice).

Can Alice and Bob after that exchange some parameters that can be used to derive IV and change it instead of exchanging the next key derivation parameters?

In essence, is it enough to send parameters for the derivation of the next IV with the message, at least for some time, or it is mandatory to change both IV and keys periodically if AES-GCM is used?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

In essence, is it enough to send parameters for derivation of next IV with message, at least for some time, or it is mandatory to change both IV and key periodically if AES-GCM used?

The requirement with GCM is that you never use the same (key, IV) pair to encrypt two different messages.

The only other requirement is that the key remains secret. Note that this secrecy requirement does not extend to the IV; we don't mind if the attacker learns it.

Hence, one common practice (once the key has been established) is that the sender uses a counter to generate the IVs. For example, use the value IV=0 to encrypt the first message, IV=1 to encrypt the second message, etc.

And, if the receiver might not receive every message in order, what the sender can do is send the IV he used along with the ciphertext. This means that the attacker learns which IV was used, however as I mentioned before, we don't care about that.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I guess that to some extent the thing I described with deriving the encryption key using ECDH assumes I satisfy "The only other requirement is that the key remains secret." requirement. The idea of using literally "counter" IV concerns me, as it exposes a piece of metadata about communication - how many messages were sent, or how long communication session goes, that is why I was thinking to use separate way to derive IV from parameters that themselves do not communicate this kind of information. $\endgroup$
    – Kote Isaev
    Aug 22 at 3:18
  • 1
    $\begingroup$ @KoteIsaev: well, normally we assume that the adversary overhears the entire conversation, and so leaking things such as the number of messages we have already sent is not a concern. However, if it is for you, well, if you have reliable transport (e.g. you're over TCP), then you can have both sides maintain a count for the IV. If you can't make that assumption, the easiest way to disguise the count might be to have the encryptor pick the starting count value randomly (rather than always starting from 0); this also gives some protection from multitarget attacks I didn't bother going into $\endgroup$
    – poncho
    Aug 22 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.