# Tag Info

2

NIST requires 128 bits of entropy to seed CTR_DRBG with AES-128, so you can safely assume that. If you ask for 256 bits of data, there is theoretically a chance that an attacker could be able to attack the RNG with a 128-bit attack: Suppose a 256-bit random value is requested twice and the attacker sees the first one, which we denote by $x_1||x_2$ (two ...

0

You should use the encryption mode for AES in CTR mode simply because everybody else does. Switching to another CTR implementation will be hell if you don't.

0

For CTR mode there shouldn't be any significant difference. However if you are looking at doing a performance test, it would be a good idea to consider the effect of system cache while measuring the encryption/decryption time. If your tests involved encrypting data in file, encryption requires disk reads. When you are performing the decryption operation ...

5

Given the choice, it is preferable to use the block encryption operation of AES, since it often faster than block decryption (never slower AFAIK). For this reason, AES-CTR is defined to use the block encryption operation of AES exclusively; that's both for AES-CTR encryption and AES-CTR decryption, which are the same operation except for IV generation/input. ...

1

The one you have in hardware. Sometimes the hardware only supports block encryption (because it is sufficient for e.g. CTR), in which case that will be faster. If the hardware supports both, there is probably no difference. I doubt many implementations only support decryption, but if you have one that does, that would be faster. The speed of raw ...

1

It is usually seen that decryption operations are slightly faster than encryption. But considering the working mode of AES, CTR uses same steps in both encryption and decryption. So It does not matter which one you use in CTR, both should give essentially same performance.

7

It is not accurate to say that the keystream from AES-CTR is a pseudorandom function. However, it is a pseudorandom generator. Furthermore, the construction that you gave is close to working but it's unclear where the key fits in. I will therefore elaborate on what we can exactly say. Let $F$ be a pseudorandom function, and for simplicity assume that the ...

-1

If $f$ is a block cipher, it is meant to be a PRP, not a PRF. However, the two are indistinguishable until about half the bit length, i.e. $2^{64}$ blocks for a 128-bit cipher like AES. (That's hundreds of exabytes.) Since you consider the CTR mode as mapping a nonce to a keystream generated with that nonce, that is a pseudorandom function. The concatenate ...

1

There's nothing wrong with using CTR mode to encrypt files, or anything else, as long as you make sure to use every nonce value only once. (And add authentication, if malleability would be a problem.) You could, for example, rewrite the whole file encrypting it with a new random nonce every time it's modified. Since you are assuming nonce reuse, an attack ...

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

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

Top 50 recent answers are included