27
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 ...
24
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'
14.7k3 gold badges39 silver badges76 bronze badges
19
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 ...
15
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 (...
15
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 ...
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 ...
13
Disadvantages:
Message length: In Cryptography, usually, the message length is not considered secret. There are approaches that you can add random values to the end or beginning or both if this is really an information leak for you. The random approach depends on your actual data case. It is also possible that a pre-determined fixed size can be used as the ...
12
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
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 ...
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
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
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
That's correct.
In most cases you can do what you are proposing. However be warned that by disregarding the authentication you clearly loose message authentication and bit flipping in AES-CTR encrypted stream is trivial.
You can do what you are proposing if the AES-GCM IV size is of 96 bits. AES-GCM supports also longer sizes for IVs and for those cases ...
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
43.8k3 gold badges89 silver badges187 bronze badges
7
Yes, there are secure alternatives to support random-access based encryption.
I did not come up with a way to break the proposed combination.
Still, instead of inventing a new mode, I would recommend to take consider existing modes for this kind of operation, such as XTS mode. The existing modes are more studied, and (in some ways) more efficient. XTS mode (...
7
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 ...
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.
...
7
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 ...
7
One gap in your proposed argument is that $ctr$ is known to the adversary (it is included in the ciphertext), whereas saying "$G_k(ctr)$ is pseudorandom" implicitly assumes that both $k$ and $ctr$ are kept secret. This is a minor point, because $G_k(ctr)$ is pseudorandom even if the adversary is also given $ctr$.
A more serious gap is that to prove CPA ...
7
There is a name for "random access PRG" : it's called a pseudorandom function (PRF). Any block cipher is a pseudorandom function (that's more-or-less the definition of what it means to be a secure block cipher), so you can use, say, AES directly. If all you have is a hash function, then the HMAC construction also gives you a PRF.
Only top voted, non community-wiki answers of a minimum length are eligible
