# Tag Info

## Hot answers tagged nonce

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). ...

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

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

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

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

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

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

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 ...

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 ...

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

NaCl's public key authenticated encryption uses a stream cipher for symmetric encryption (after key derivation using Curve25519). Like all synchronous stream ciphers, it produces the same keystream when you use the same nonce. That means you are in the same position as when a one-time pad has been reused. (Having a known plaintext would make things even ...

2

AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ...

2

TLS has different keys for the two different directions. That is, the server-to-client connection is encrypted with one set of keys, and the client-to-server connection is encrypted with another. Both sets of keys are derived at the same time, however they are distinct. Because the keys are distinct, using the same nonce isn't an issue. Technical point ...

2

As pointed out the nonce must be unique so hash of key only is not going to work. You could however hash the key and plaintext together to produce a secure nonce: $n = H(m|k)$. Note that this would still result in the same ciphertext for identical plaintext. So it doesn't fulfill the requirements for the ciphertext to be indistinguishable.

2

Let's look at your requirements: have a large IV — specifically, one large enough that using a CSPRNG to generate a fresh IV each time is secure. Generally, IVs/nonces longer than 96 bits are thought to be okay for random generation. If it is at least 128 bits you can safely use it as long as you can a 128-bit block cipher like AES, because before you ...

2

Is it safe to use non-random nonce in GCM? Say I use 0x1 for m1, 0x2 for m2, so on. It is perfectly safe to use a non-random nonce in GCM, as long as you never reuse a nonce for two different messages. So, if you use the message count for the nonce, that's fine; if you accidentally forget that you used nonce 0x5 for a message, and use that again, well, ...

1

If you reuse a nonce, you lose confidentiality for the messages with that nonce. Messages with other nonces retain their confidentiality. However, the attacker can also attack the MAC part (Poly1305) and generate a third and more messages with the same nonce. See: Why is Poly1305 popular given its 'sudden death' properties? So unless you have a way ...

1

No, the nonce is not fit to be a HMAC key, because anybody can view the nonce in transit. If - on the other hand - the TLS connection does deliver enough security then you would not need the HMAC. It's fine to use the nonce as one time code, but you don't need the HMAC for that. If an attacker can obtain nonce's send to clients than the attacker can always ...

1

The authentication tag in GCM is generated by XORing a block cipher output with the Galois field hash (and truncating it for shorter lengths). It is thus assumed to look PRF. So it is effectively just a random nonce that should not collide until a birthday bound of $2^{t/2}$. With a tag length of 96 or more bits, it should be secure. Shorter random IV ...

1

The answer is that it depends very much exactly on what you are considering. However, better bounds can be achieved by using a 96 bit nonce and a 32 bit counter. This is certainly true for GCM as was proved in this paper (Breaking and Repairing GCM Security Proofs). Note that GCM uses CTR inside, so this is relevant.

1

I don't understand the difference between the split nonce/counter design and simply using a random value and incrementing. Why is using nonce +/⊕ counter insecure whereas nonce || counter is secure? Here's the context of your Wikipedia quote (my bold): If the IV/nonce is random, then they can be combined together with the counter using any lossless ...

1

As far as I understood the method of creating the 128 bit counter in the NIST documents is more or less kept open. There are some hints of deriving the counter, but NIST is essentially saying that anything is secure as long as the counter is unique. Using a starting value of 128 bits is certainly feasible and often required. Java providers - for instance - ...

1

The following picture shows EAX: As you can see there is a OMAC calculation (or CMAC as it is usually called) over both N (the nonce) and H (the header / associated data). With regards to security it doesn't matter where you place the nonce and the other data in the header. I'll not go into the security of XOR'ing the calculated OMAC values for nonce, ...

1

Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ...

1

This is a trickier question than you might think. The first thing to note is that your scheme doesn't respect record boundaries. TLS 1.2 seems to have been rewritten to use a random IV for CBC mode encryption for each record (to avoid certain attacks). It is therefore likely that the idea of TLS 1.2 is to respect record boundaries. The document "AES Galois ...

1

The standard approach is to have the sender pick his nonce (either randomly, or as a counter), and send it with the packet. The decryptor then knows what nonce to use to decrypt, because it's right there. Because nonces aren't assumed to be secret, this works.

1

If your nonce is 16 bytes, and your message pre-nonce is a multiple of 16 bytes (i.e. no padding is needed), sending the nonce in the clear opens you up to replay-ish attacks. Specifically, if an attacker captures one exchange with nonce $N$ and response $R$ (with $b$ blocks $R_1$ through $R_b$), and then impersonates the server and the client sends them ...

1

Unrelated to your question premise, but highly related to the security of the overall scheme is that you may be opening yourself up to a side channel attack. Your supposition about the randomness may hold true as long as the hardware is secure, but if someone gains access to the device, they may be able to make your numbers less than random. This may range ...

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