# Tag Info

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

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

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

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

The treatment of nonces is the same for most stream ciphers, they only differ in length. In the case of Salsa20 the nonce is 64 bits, and there is a related cipher XSalsa20 which extends the nonce to 192 bits. The caller/application provides the nonce. Typically the protocol or file format you're implementing specifies how to treat the nonce. The essential ...

2

The once part inside of the nonce in CTR mode means effectively "once for this particular key". If you use a fresh key for each message (e.g. by encrypting it using public-key crypto or similar), you can use the same nonce for all the messages (or a size-zero nonce). The important part is that the combination of nonce and ctr-value (i.e. what is input into ...

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

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

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

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

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

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