# Tag Info

12

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

7

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

4

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

4

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

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

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

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

Nonces must be unique but are not secret. Typically you send it alongside the ciphertext as a prefix. Note that with the asymmetric box, you must not use a nonce that you used in one direction in the opposite direction, since both directions use the same shared symmetric key. Reusing a nonce is a fatal mistake. It completely breaks the MAC and it leaks the ...

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.

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

It is not clear what you are attempting to do. AES in itself does not need a nonce, it only needs a key. If you are using an algorithm which uses AES, such as AES-GCM then the nonce must never be reused (In general when using cryptographic protocols, never reuse a nonce!). If by global value, you mean one which is constant, this ruins the security of any ...

1

Well, you have it right in how nonces are used to make sure that the keys in different SSL sessions; this effectively prevents someone from taking an SSL record from one session, and injecting it into another -- because the keys aren't the same, it won't pass the integrity tests. However, that's not the only place we care about replay attacks; we can also ...

1

In the traditional sense, a nonce is a number that is only used once (with the same key). Though occasionally there are other requirements. For example, we may require that the nonce be unpredictable. For more on this I recommend you read this answer and this answer. Now, you don't go into enough detail on what you are doing to say whether or not you need ...

1

Passwords should use a password hashing function. Password hashing functions are different from basic cryptographic hashes, though they use cryptographic hashes as part of their construction. Password hashing functions must use salt. (Password hashing functions can also tune their time and/or memory usage, cryptographic hashes generally can't.) So for your ...

1

Yes, it's a bad idea. Take for instance the encryption part, and assume a stream cipher (as used in NaCL). The messages may be unique, but as the stream cipher requires a unique nonce you would loose all confidentiality! The easiest thing to do is to simply use a (random) nonce even if not strictly required. If you cannot do that because of bandwidth ...

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