39
I wrote a rather lengthy answer on another site a few days ago. Bottom-line is that CTR appears to be the "safest" choice, but that does not mean safe. The block cipher mode is only part of the overall protocol. Every mode has its quirks and requires some extra systems in order to use it properly; but in the case of CTR, the design of these extra systems is ...
26
Yes, the attacker would have a realistic chance of recovering plaintext, and preventing him from knowing the IV values does not reduce this risk.
The problem is that CTR mode encryption is effectively:
$C = P \oplus F(Key, IV)$
where $P$ is the plaintext, $C$ is the ciphertext, and $F$ is a complex function of its two inputs.
The problem with this is if ...
22
Suppose you use the sector number times the number of AES blocks per sector as the initial value for CTR. If you successively store the content $M$ then $M'$ in the same sector $n$ then $E^{CTR}_n(M) \oplus E^{CTR}_n(M') = M \oplus M'$ (where $E^{CTR}_{n}$ is the encryption function with CTR mode and IV started for sector number $n$). CTR mode fails ...
answered Feb 21 '14 at 15:39
Gilles 'SO- stop being evil'
12.4k3 gold badges34 silver badges65 bronze badges
22
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 ...
18
There are some serious problems with this design that would preclude it from being standardized, so it probably does not have a name.
The 2 visibly main flaws are as follows:
If the plaintext follows a pattern similar to the block counter, the
block cipher inputs may repeat, exposing information about the
plaintext (exact same issue as reuse of nonce, but ...
14
As the name suggests, CTR mode works by encrypting a counter (that gets incremented with each 16-byte block) to generate a stream of random bits. That bit stream is then XOR'ed with the plaintext to create the ciphertext. The IV provides the initial value for the counter.
CTR mode is secure as long as the probability of a counter value repeating is ...
14
Short answer:
There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group.
Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political (...
13
While you do operate block-by-block when generating the pseudorandom stream, the actual encryption step (i.e., the XOR) is bitwise, and therefore does not require the message to be padded.
For example, the message "Hello" will be processed as follows (pseudocode):
byte stream[16] = AES(Key, Nonce);
byte plaintext[5] = "Hello";
byte ciphertext[5];
for i ...
13
AES-CTR is a stream cipher, of a particular kind where the keystream is obtained by encryption of a counter. So the question reduces to: what are drawbacks of AES-CTR compared to other stream ciphers?
The main ones compared to ChaCha20 are:
Without hardware support, AES can fail to cache-timing attacks.
Without hardware support, AES is slower.
Without ...
13
I believe that he was referring to the misconception that the birthday problem that arises in encryption is only when you use the same counter twice. If a random IV is used, then such a counter repeats at $2^{32}$ blocks with high probability (and if you want a $2^{-32}$ safety margin then you can only encrypt $2^{16}$ blocks). However, if distinct counters ...
11
In general, CTR mode is not secure against chosen-ciphertext attacks. (The same goes for the other classic block cipher modes of operation too; to get security against chosen-ciphertext attacks, you need authenticated encryption.)
In your stated attack scenario, the attacker can obviously use the decryption oracle to decrypt any ciphertexts they intercept, ...
11
The reference for this is NIST SP800-38A, especially its appendix B.
Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ...
11
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 ...
10
Key/IV pairs should not be reused for either AES-CTR and AES-CBC - or for any other symmetric cipher for that matter. As a cipher is a Pseudo Random Permutation (PRP) inserting the same input will result in identical output. If a key/IV pair is reused then information is leaked to an attacker; the attacker can distinguish data with the same contents.
CTR is ...
10
Assuming that you can indeed guarantee that the keys will never be reused, both schemes should be secure.
The only requirement for the nonce in CTR mode is that it must be unique (and, if used directly as the initial counter value, not equal to any intermediate counter value used in the past or in the future). If you're only encrypting one message with a ...
10
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, ...
10
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
The CTR mode of encryption is defined in general for any cryptographically strong pseudo-random function (PRF). You can build such a PRF from a hash function.
For CTR, you produce a key stream by concatenating:
$$F(k,0) || F(k,1) || ... || F(k,m)$$
where $F$ is your secure PRF, $k$ is your key, and $m$ is the the length of your plaintext divided by the ...
9
There are probably quite a few good reasons for this, although I don't expect that a scientific answer can be composed (as you would need to use a survey, and I've never heard of such a thing for modes of operation).
Let me list a few possible reasons:
Developers don't know about CTR mode of operation; most questions on StackOverflow are about ECB and CBC (...
9
Yes, but to use a known algorithm that specifies precisely that, take a look at the SIV mode of operation . "SIV" stands for Synthetic IV. IV is the initialization vector, which is the nonce (or the nonce and initial counter value, depending on the definitions).
Unsurprisingly it relies on CTR mode for confidentiality and CMAC for the authentication tag ...
9
I understand that it would be quite inefficient as the key schedule would need to be re-calculated for every block, but would it make cryptanalysis easier?
It would make cryptanalysis trivial.
If the attacker knows that
$$P_i \oplus C_i = E_{n \mathbin\| i}(k)$$
and he knows $n, i, C_i$ and has a guess for $P_i$, he can recover $k$, and use that to ...
8
I would like to ask if that is true for every AES CTR mode implementation?,
Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can begin ...
8
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.
...
8
If we were to use CTR, what would you think of using a checksum on
plain text then encrypt whole.
That's a really bad idea (from a security perspective).
Here are the reasons for this:
Depending on your checksum, there are immediate obvious attacks on the authenticity of messages. If your checksum is CRC for example then it is linear. This means that an ...
8
You can safely use HMAC-SHA256 instead of the SIV mode custom PRF to derive the nonce/authentication tag. There's some caveats:
HMAC-SHA256 gives a 256-bit output; you'll have to truncate it to the nonce size.
HMAC-SHA256 takes in a single bit string, so it can't distinguish the boundary between a header (unencrypted associated data) and payload (encrypted ...
answered Mar 31 '19 at 20:14
Squeamish Ossifrage
40.7k3 gold badges78 silver badges167 bronze badges
7
First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments.
Now, some observations. I haven't read all your code, so I may misunderstand things.
Is this a good way to whiten the data? Is ...
7
No.
There is a difference between the type of a cipher and the construction of a cipher. If a cipher is of a specific type for which there are known IND-CPA secure constructions then that doesn't mean that an entirely different construction is secure. There are known attacks on stream ciphers, including "modern" stream ciphers such as RC4.
A stream cipher ...
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 ...
7
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.
...
Only top voted, non community-wiki answers of a minimum length are eligible
