What are the main differences between a nonce, a key and an IV? Without any doubt the key should be kept secret. But what about the nonce and the IV? What's the main difference between them and their purposes? Is it only that, in literature and in practice, an IV is being used as "initiator" of a block cipher encryption mode which should be unique? And the same property should hold for a nonce as well, but since it doesn't instantiate something we call it a nonce? I.e: in AES-CTR mode the IV is a nonce+counter. And both are put in plaintext format in the beginning of the ciphertext.
2 Answers
A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.).
(There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which allows decryption and/or signing, and a public key (derived from the corresponding private key) which allows encryption and/or signature verification.)
An IV or initialization vector is, in its broadest sense, just the initial value used to start some iterated process. The term is used in a couple of different contexts and implies different security requirements in each of them. For example, cryptographic hash functions typically have a fixed IV, which is just an arbitrary constant which is included in the hash function specification and is used as the initial hash value before any data is fed in:
Conversely, most block cipher modes of operation require an IV which is random and unpredictable, or at least unique for each message encrypted with a given key. (Of course, if each key is only ever used to encrypt a single message, one can get away with using a fixed IV.) This random IV ensures that each message encrypts differently, such that seeing multiple messages encrypted with the same key doesn't give the attacker any more information than just seeing a single long message. In particular, it ensures that encrypting the same message twice yields two completely different ciphertexts, which is necessary in order for the encryption scheme to be semantically secure.
In any case, the IV never needs to be kept secret — if it did, it would be a key, not an IV. Indeed, in most cases, keeping the IV secret would not be practical even if you wanted to since the recipient needs to know it in order to decrypt the data (or verify the hash, etc.).
A nonce, in the broad sense, is just "a number used only once". The only thing generally demanded of a nonce is that it should never be used twice (within the relevant scope, such as encryption with a particular key). The unique IVs used for block cipher encryption qualify as nonces, but various other cryptographic schemes make use of nonces as well.
There's some variation about which of the terms "IV" and "nonce" is used for different block cipher modes of operation: some authors use exclusively one or the other, while some make a distinction between them. For CTR mode, in particular, some authors reserve the term "IV" for the full cipher input block formed by the concatenation of the nonce and the initial counter value (usually a block of all zero bits), while others prefer not to use the term "IV" for CTR mode at all. This is all complicated by the fact that there are several variations on how the nonce/IV sent with the message in CTR mode is actually mapped into the initial block cipher input.
Conversely, for modes other than CTR (or related modes such as EAX or GCM), the term "IV" is almost universally preferred over "nonce". This is particularly true for CBC mode since it has requirements on its IV (specifically, that they are unpredictable) which go beyond the usual requirement of uniqueness expected of nonces.
-
2$\begingroup$ Therefore iv could be ignored? Thanks & Regards, Clara $\endgroup$ Jan 30, 2019 at 1:52
-
1$\begingroup$ @ClaraYeung For CTR, you can use a null (all zero) IV/nonce if you wish, as long as you don't encrypt multiple messages with the same key. Just make sure the key:nonce tuple never repeats. $\endgroup$– forest ♦Jan 30, 2019 at 5:57
The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret.
A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something better. A initialization vector is also used as input for a cryptographic primitive to achieve randomization of normally deterministic primitives. Stream ciphers are called stateful where the same key is used for many states and the nonces are used to ensure different key streams. For this reason, we use IVs for the modes of operations of block ciphers but nonces for stream ciphers. This is a little bit confusing when we talk about AES-CTR because we use the term IV for the block cipher and the term nonce+counter for the state of the stream cipher.
For the sake of completeness, a salt is also some kind of initialization vector for one-way functions but with the goal to achieve additional entropy for low-entropy inputs, e.g. password hashing.
-
6$\begingroup$ Nonces should generally not be randomly generated but instead iterated using a counter as wide as the nonce. This guarantees the nonce will not be reused (for the full $2^n$ period of the counter). A suitable randomly generated value can be statistically unlikely to produce a duplicate nonce, but a counter removes the possibility entirely. Nonce reuse is typically fatal to the security of a cryptographic primitive. Cheers. $\endgroup$ Aug 25, 2018 at 18:43
-
2$\begingroup$ Careful - a) nonces sometimes also need to be unpredictable, and b) computers operate here on Earth - hardware flaws, cosmic rays, etc that break the uniqueness of a counter are far more likely than than a birthday-problem collision in a 192-bit random number. Don't depend on a counter's uniqueness. $\endgroup$– JasonOct 12, 2020 at 9:05
-
$\begingroup$ It also bears noting - in a distributed system, a large random number is much less error-prone to implement than a unique counter. i.e. it's a design with fewer "bug" insecurities. $\endgroup$– JasonOct 12, 2020 at 19:25