Hot answers tagged

9

You would not just need a mode of operation for what you're asking. What you need is a secure transport protocol. Probably the best well known one for TCP connections is TLS of course. For UDP connections you could use DTLS. If you have a shared key you could use one of the pre-shared key (PSK) variants. If you want to create your own transport protocol you ...


9

I would pick e) none of the above. None of those modes offers integrity protection, so unless integrity is handled elsewhere, your application is wildly insecure. An attacker could modify bits in transit and do nefarious things. Of the three, CFB and CTR are the worst for the application and should be very easy for an attacker to mount successful attacks, ...


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


6

Your intuition is on the right track: if you run a pseudorandom function in counter mode with your secret key, you get a stream cipher. Some stream ciphers are designed like this, perhaps most notably Salsa20 (and its later variant ChaCha20). But the key to answering your question, as I see it, is to note that a collision-resistant hash function like SHA-2 ...


6

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


6

The modes you are referencing are specifically modes of operations for block ciphers, and therefore are not directly applicable to hash functions. Block cipher operations take 2 inputs, the key and a block-sized input value, and output a block-sized keyed permutation of the input. Hash functions take a variable length input, and output a fixed length value. ...


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

You are correct. The $Update$ function is called after each invocation of the $Generate$ function, and this does mean that chunking affects the output. Changing both the key and the nonce of an $AES-CTR$ key stream generator to uniformly selected (pseudo) random values will, of course, make the resulting key stream uniformly independent from what it would ...


4

For my answer I'll distinguish two cases: a) By "streaming" you mean "online" and b) by "streaming" you mean "can encrypt arbitrarily sized messages". See the CAESAR survey paper for the notions I use here. There can be no fully nonce-misuse resistant online authenticated encryption scheme, i.e. a scheme where the only information leaked upon nonce reuse ...


4

Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely known ...


3

This is a type of chosen-plaintext attack, where the adversary gets partial choice of plaintexts — they can cause the same substring to be encrypted multiple times. AES-CTR, if used properly, is resistant to chosen-plaintext attacks. Used properly, for CTR mode, means that the same counter value must not be reused for different messages. For example, if ...


3

A slight correction about terminology: The key is constant when you use CTR. The IV/counter affect the cipher input and so the keystream varies. The reason this can be decrypted is that the decrypter knows both the key and the IV/counter. They can calculate exactly the same function as the encrypter did, resulting in the same keystream block, which a XOR ...


3

Summing up the discussion in the comments: What you are describing is the CTR Mode of operation of block ciphers, which requires an encryption function ("E" in your diagram) like AES. So, "should I use CTR or AES?" should instead be "should I use AES with CTR or with another mode?" As @RickyDemers already mentioned, CTR mode (without any additional ...


3

From your question I'll assume that you do not plan to use strong means of authentication along with CTR encryption. If you do, the first point is invalid. Never ever use CTR mode alone. If you use CTR mode alone (i.e. without authentication) you allow attackers bit level precision for changing files. This can result in very undesirable decryptions where ...


3

Yes, this is secure. (one of the few cases where I'm pretty confident about this). Here are the arguments: Combining a secure (e.g. SUF-CMA) MAC with a secure (e.g. CPA-secure) encryption method in encrypt-then-authenticate is generally proven secure. This was shown in "Authenticated Encryption: Relations among notions and analysis of the generic ...


3

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


2

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


2

CTR consists of two parts: construction the key stream using a counter, and XOR-ing the output of the key stream with the plaintext/ciphertext. The key stream can be generated using a PRF, in which case it is of course not invertible. The key stream can also be created using a PRP (e.g. a block cipher like AES) in which case it is invertible. As indicated, ...


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


1

Basically there are two ways: decode the counter to be a big number in some kind of library, increase that number, then encode it back as unsigned, statically sized, big endian value, making sure you left pad with zero valued bytes when necessary; increase the value of the right-most byte (highest index) as unsigned number, if the resulting value is zero ...


1

Modern computers are quite fast, and modern cryptographic algorithms are quite efficient. Most computers benchmark hardware accelerated AES in CTR mode well above 1GB/s, which would be a fraction of a millisecond for a 100KiB file. Since the standard system timer generally runs at 1ms intervals, the entire encryption operation ([file data] XOR [AES] XOR [...


1

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.


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


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.


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

I was doing something like this, and discovered just how careful you need to be. I wanted to do password encryption using widely available primitives so that I could do re-keying within MySQL easily. I was already doing AES256 CTR and following the prescribed usage to the letter. fileKey = random256Bits() ivPerWrite = random256Bits() //version 1 of the ...



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