Hot answers tagged

13

By the modern definition of a cipher, it must be possible to encipher several messages with the same secret key. That's also a practical necessity, due to the difficulty of securely establishing a shared secret key. That issue is solved with the nonce, which is not secret, and can be transferred as part of the ciphertext (typically: at the beginning). ...


10

The article on NaCl by its authors touches this subject. I'll quote here the relevant bit: Nonces. The crypto_box API leaves nonce generation to the caller. This is not meant to suggest that nonce generation is not part of the cryptographer’s job; on the contrary, we believe that cryptographers should take responsibility not just for nonces but ...


8

The Intel post which I think you mean was discussed in this question and as I wrote there, the limitation only applies in the case of trying to combine PRNG outputs into values larger than the seed entropy (two 256-bit values in their case). Also mentioned there: cryptographic mixing does not increase the entropy you have, so if concatenation is insecure, ...


7

With CBC mode the initialization vector is referred to as IV, because it is not nonce. There are ways to construct nonce so that it does not meet the needs of CBC mode. Random IV is one generation choice which is usually fine. Nonce can also be a counter, which is not ok here. Definitions Nonce means number used once. IV means initialization vector. CBC ...


7

The answer is that you can do exactly what you say. Initialize the counter to a random 16 byte number and start counting. Wikipedia (not sure if that is where you got the idea that it must be 8 bytes and 8 bytes) has the following note: The IV/nonce and the counter can be combined together using any lossless operation (concatenation, addition, or XOR) to ...


7

I assume you mean AES-GCM. Nonces must be unique for any use of a key. Given that $n = H(k)$ is constant for constant key $k$, this implies that such a nonce may only be used once, ever. Nonce reuse is particularly catastrophic in GCM mode (as with any other CTR-based mode), as it causes the keystream to be identical. Essentially, you wind up with two (or ...


6

Yes, a nonce is a number not used more than once. In its purest sense there should be no other requirements than this, i.e. randomness or unpredictability should not be necessary. However, in certain settings stronger requirements are put on the nonces; like for instance in the CBC-mode of operation for block ciphers the IV (nonce) needs to be ...


6

Yes, it is safe. The only requirement for the nonce in Salsa/Chacha is to be unique; being predictable is not an issue, so a counter is fine. Like CodesInChaos indicated, I believe extending XSalsa20 to XChaCha20 would also work if you want to a larger nonce, but have nothing concrete so will leave the details to him/her.


6

My only idea is that B authenticates himself to A, because if A later decrypts it, A will see whether B was able to decrypt it. But why would you need to increment the nonce? Correct, that's the idea. If B didn't need to increment the nonce and just encrypted the same value, the message sent back would be the same that A sent, so an attacker would be ...


5

Under the assumption that $(K,\text{Msg})\to H_K(\text{Msg})$ is a secure MAC (be it HMAC or any other MAC), and $\text{Nonce}$ does not repeat and is of fixed size, both $H_K(\text{Msg}||\text{Nonce})$ and $H_K(\text{Nonce}||\text{Msg})$ are demonstrably secure, in the sense that an adversary not knowing $K$ can't distinguish either from random, even for ...


5

A 6-byte nonce can expect to receive a collision 0.01% of the time after around 240,000 nonce generations (based on a birthday attack). After 100 such rotations (a little under 17 years, based on your 2-month rotation policy), that comes out to a likelihood of just under 1% of experiencing a collision. On the surface, to me that seems like a reasonable ...


5

Suppose you do CTR mode as: $E(k,nonce+1) \oplus m_1$, $E(k,nonce+2) \oplus m_2$, $E(k,nonce+3) \oplus m_3$, etc. The wikipedia page is talking about a non-random nonce, with a specific example of a packet counter. So suppose $nonce$ is a packet counter and in each packet you encrypt several blocks. You might end up with the following: In packet #$p$: ...


5

What you're describing is pretty similar to the SIV block cipher mode. It also uses a deterministic function of the message to derive the nonce for CTR encryption. Under some pretty widely accepted assumptions about HMAC-SHA256 this is a perfectly fine way of achieving deterministic authenticated encryption. It doesn't meet IND-CPA (as you pointed out) but ...


4

The synthesized IV does not need to be random. AES-SIV is a deterministic authenticated encryption mode: it can be used without any nonce when it is not a concern if the attacker can tell that the same message is being transmitted (under the same key) multiple times. Privacy and authentication are still guaranteed. SIV recommends to use a nonce (more ...


4

Yes, if the client and the server use the same key to encrypt their messages (instead of having separate keys for client-to-server and server-to-client communication), then you need to ensure that they cannot ever use the same nonce. One way to do that would be to, say, let the client use only even nonce values, and let the server use only odd nonce values. ...


4

Definition 10.9 in Chapter 10 of Handbook of Applied Cryptography. A nonce is a value used no more than once for the same purpose. It typically serves to prevent (undetectable) replay. Continuing on, there is some additional info that you might find interesting. The term nonce is most often used to refer to a “random” number in a ...


4

There is not much difference and in practice the terms are often used to mean the same thing. In this context however the Nonce does not have to keep to the random properties that the IV has. As explained in the paper: A probabilistic encryption scheme $C = \varepsilon^R_K (P)$ is an IV-based encryption scheme, syntactically, but we are suggesting that, ...


4

The only limitation that you really have to consider is that of nonce collisions. With 128-bit random nonces, you would expect collisions after about $2^{64}$ nonces due to the birthday bound. Even if you stored all 30 fields of all 50 million rows thousands of times (you need a new nonce if a field is rewritten), you would still have a chance smaller than ...


3

This is vulnerable to a length extension attack. Given a valid nonce/MAC, the nonce can be extended to forge a new valid nonce/MAC value. This is because $m_4$ is appended to the end inside the outer hash. How this affects you will depend on how you validate your nonce. But in general, this is not a secure construction. There's probably more things wrong ...


3

Just to be sure we're on the same page, I interpret your question as defining encryption of a string $P_1 P_2 \cdots P_\ell$ with a counter $\mathsf{ctr}$, key $K$, and an $n$-bit blockcipher $E$ as follows: $$ \mathcal{E}_K(\mathsf{ctr}, P_1P_2\cdots P_\ell) = C_0 C_1 C_2 \cdots C_\ell$$ where $C_0 = E_K(\mathsf{ctr})$, $C_{i+1} = E_K(C_i \oplus P_{i+1})$, ...


3

Let $2^m$ be the average message length in blocks. When using an independent random nonce for the whole 128-bit IV of each block, you would expect a collision after $2^{64}$ blocks, i.e. $2^{64-m}$ messages. (But you double the data size.) When using a 96-bit nonce and a 32-bit counter, you would expect a nonce collision after $2^{48}$ messages. This is ...


3

You looked on version 1.49 where OCB was not fully implemented as it seems. Actually OCB uses only 120 bit nonce, the other 8 bits are encoded as described in the RFC. Have a look at version 1.50. There OCB seems (nearly) fully implemented and an exception is raised, if the given nonce is longer than 15 bytes (source code line #158).


3

Should the external nonce passed to GCM be authenticated separately when passing over network? No, that is not necessary; it is implicitly authenticated by GCM itself, pretty much as the AAD is also authenticated. That is, if someone in the middle modifies the nonce, then that will alter the authentication tag that the decryptor computes as a part of ...


3

Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for ...


3

To answer your first question, the incrementation is required in order to prevent spoofing of that message. An attacker could send back the same encrypted nonce claiming to be Bob. However, if Bob incriments the nonce and sends it back encrypted, Alice would know for sure that Bob has received the nonce and has incremented it. Now, Alice encrypting the ...


2

Like Ilmari Karonen wrote, you can ensure that nonces picked by two senders do not collide by reserving one bit (like the lowest) to differentiate them. If you use random nonces this is not required, since the probability that a random nonce collides depends only on the total number of nonces generated, not who generates them. In fact, reserving a bit would ...


2

I'll give another answer in case you or someone else needs to work with that version of OCB and/or Bouncy Castle. My understanding of this check is that if the nonce is longer than 16 bytes, or the nonce is 16 bytes and the first bit of the first byte of the nonce is not 0 (assuming big endian), then an error is thrown. Do I understand this ...


2

There may be some particular scenarios where an unpredictable nonce is better than just a unique nonce. For example suppose you have access to an oracle that can generate the correct response to an authentication request that involves a nonce, but you don't have real time access; in particular by the time you get the response from the oracle, the challenge ...


2

Relying solely on randomization for the block counter is actually more likely to cause a nonce collision in case of a system time reset. This only gets worse as the message length increases. This is further exacerbated if the PRNG takes the system time as input, or does not have enough seed entropy. There is also no reason for the static 0 byte in the nonce. ...


2

Since the counter values are not authenticated, an attacker can try to swap the order of messages in order to modify things. If a message arrives out of order, the MAC will be correct, since the ciphertext has not been modified, but after decryption, the first block of message will be messed up and the rest of the message left intact. Will this be enough to ...



Only top voted, non community-wiki answers of a minimum length are eligible