38
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
You say that a random IV "would also be unique", but really that is the crux of the problem. The problem with counter mode is that it is secure unless the same counter is used twice; if it is, it is likely that an attacker will be able to recover both plaintext messages. This contrasts with CBC mode, which if you repeat an IV, it has the relatively benign ...
21
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 ...
20
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 ...
16
Well, as far as we know, the mode you suggest should be secure. Now, to be honest, AES256 versus your mode isn't quite a fair comparison; your mode gives somewhat less theoretical security; if you encrypt a known $2^n$ block message, the key can be recovered with $2^{256-n}$ effort; however, this observation doesn't really affect the practical security.
...
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 ...
12
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
It is an IV and it is safe to transmit with the ciphertext (if it wasn't, we would call it a key).
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
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
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
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 (...
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
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
Personally I like the modes that support integrity checking and authentication, e.g. GCM, as they only require one key, and are not vulnerable to changes in the cipher text. One particular important problem area is padding oracle attacks, which are much more common than people seem to admit.
Note that GCM/AES is - just like CTR - a block cipher in stream ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
