# Tag Info

## Hot answers tagged nonce

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

6

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

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

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

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

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.

4

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

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

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

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

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

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

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

2

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

2

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})$, ...

2

An IV is an intial vector, which means it is an initial vector of data used when you start a chaining mode. It has no interesting properties of its own. If the IV is a nonce, that means it is a number used once (eg CTR mode). This means that (by changing the IV) we ensure that the process is never run on exactly the same input data (even if messages are ...

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

1

All the security definitions I am aware of for a cryptographic hash functions remain the same, if you apply a 1:1 mapping before hashing. In other words, if $f$ and $g$ are each others inverse, and $h$ is a secure cryptographic hash, then $x \to h(f(x))$ is also a secure cryptographic hash according to any security definition, I know of. Under such ...

1

The attacker acts as a man-in-the-middle and can forward the clients nonce to the server and the servers nonce to the client. As a result both parties establish a connection with the attacker using the same nonces. Because of a weakness in the TLS protocol, the two connections can have the same key, and this key is known to the attacker. After resumption ...

1

Yes, as long as you obey all the total usage limits and choose the IV appropriately (see below). Whilst IV is a general term for any initialisation vector the recent trend has been to use the term 'IV' to refer to a random vector, and "nonce" (a contraction of "n-umber used once") to refer to an input vector that need not be random, but cannot be repeated. ...

1

IV (initial value or initialization vector) is a vague term that describes some kind of starting value for a mode of operation that is known to both parties, and generally sent in the clear with the encrypted data (and known to the attacker) IVs in many modes of operation have specific requirements to that mode. In some modes the requirement is that is ...

1

An even more robust approach could be to use something like SIV mode (RFC 5297) with a nonce composed of a timestamp and a random value (and possibly, if practical, a message number). Basically, when encrypting a message, SIV mode first computes a MAC of the plaintext and the nonce (and any other associated data) using a modified form of CMAC, and then uses ...

1

The "shortest possible amount of overhead for describing ciphertexts" is achieved by encrypt(key,nonce,plaintext) = prefixfree(length(nonce)) || FPE ( length(nonce)+length(plaintext) , PRF(key,length(nonce)+length(plaintext)) , nonce || plaintext) The basic idea is to use independently keyed block ciphers for each possible plaintext length, and ...

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