"Weak" implementation of AES-CTR?

Question

Assume an instantiation of AES-CTR like in the following picture:

Some details on the input-values for keystream generation:

• COUNT: a 32-bit value associated with the transmission mode
• IV#1: a 5-bit value that can be assumed constant for a specified transmission
• IV#2: a 1-bit value indicating the direction of the transmission
• incr: a 64-bit value initialized to 0 and then incremented per standard $\bmod 2^{64}$ increment function.
• cipher key: refers to ciphering key which is obviously not known

Assume that all those input values are not difficult to identify/guess as they are required to establish correct transmission and synchronization between the two communicating parties (e.g., direction, radio info, etc). We also assume that no pairs of ciphering keys and input values ($COUNT||IV\#1||IV\#2||0^{26}||incr$) are used. Is this a weak AES-CTR implementation, assuming one can obtain pairs of keystreams/input-values?

I guess we can say this implementation is malleable as any AES-CTR without authentication steps. Any other weaknesses?

Answer 1

If the implementation ensures that no (COUNT, IV#1, IV#2) tuple can ever be used more than once, and if no tuple is ever used to generate more than 2⁶⁴⁺⁴ bytes of keystream output, then this scheme is as secure as any instantiation of AES-CTR can be. Of course, as CTR is not an authenticated encryption mode, it will still be malleable unless combined with a MAC.

Conversely, if an attacker can cause two plaintexts to be encrypted with the same COUNT, IV#1 and IV#2 values, then they can easily obtain the bitwise XOR of the plaintexts, which may be sufficient to at least partially recover the plaintexts themselves. In particular, if an attacker can cause a plaintext of their choosing (or at least known to them) to be encrypted with a chosen COUNT, IV#1 and IV#2, then they can fully decrypt any other plaintext (of equal or lower length) encrypted with those same values.

Your question does not contain enough information to let us tell which of these two scenarios applies, and so we cannot say whether this specific AES-CTR instantation is secure (in the usual IND-CPA sense one would expect of CTR mode) or not.

That said, the short length of IV#1 certainly raises some concern. You have not described exactly what constitutes a single "transmission" in this protocol, but whatever it is, there can be only 32 of them in this scheme before you'd need to rekey (assuming that nothing prevents two transmissions from using the same COUNT values). That seems like it might be a problem.

Answer 2

Assume that all those input values are not difficult to identify/guess as they are required to establish correct transmission and synchronization between the two communicating parties.

If we assume that the key is secure then the mode of operation will also be secure for the security that it was designed to deliver. That the IV may be public is a common assumption: it does not in itself make the resulting cipher insecure.

Is this a weak AES-CTR implementation, assuming one can obtain pairs of keystreams/input-values?

It is hard to read what you mean here, but lets assume that:

• keystreams means ciphertext;
• input values means the components that make up the IV.

instead of the normal definition:

• keystreams means the output of the block cipher that get XOR'ed with the plaintext
• input values means the plaintext.

In that case the scheme would still offer confidentiality - presuming that there aren't any protocol or implementation mistakes.

---

Obviously if you do get access to part of the keystream generated by AES CTR - the part that gets XOR'ed with the plaintext - then you can decrypt that part of the plaintext, but not any other part of the plaintext.

You should only be able to get to parts of the keystream by either:

1. knowing that part of the plaintext - this doesn't help the adversary because that part of the keystream is not linked to any other part of the keystream;

2. knowing the key - this obviously breaks the cipher completely: once the key gets known all security assumptions are broken.

Note that the block cipher will protect the key. Furthermore the IV may be get known to an adversary. So knowing part of the key stream does not break security of CTR.

Knowing all of the keystream implies knowing all of the plaintext of a message or to know the AES key. In the first case no mode of operation can protect that particular message as the plaintext is already known. Other messages would still be secure. If the key gets known then the adversary can simply decrypt anything and all security is lost.

I guess we can say this implementation is malleable as any AES-CTR without authentication steps.

Of course it is malleable. There is nothing to authenticate the plaintext or ciphertext after all.

There aren't any other obvious attacks on CTR mode as long as the IV doesn't repeat or if the key gets known.

There is a copious amount of bits reserved for the counter, so it is clear that the message size is not an issue.

---

The IV seems to be build up well.

There is 32 bits space for a message counter. This allows for over four billion messages to be send before the counter starts to repeat. Do note that if the adversary can trigger messages to be send that this could become a problem: a computer can easily perform more than 4 billion calculations after all.

The transmission is identified by the next 5 bits and the direction in the one after. You could argue that those 6 bits should be before the message counter semantically, but in that case the 32 bit counter would not be 8 bit aligned, making the counter encoding non-trivial. There are obviously only 32 "transmission" connections possible. In general it is nicer to calculate a different key for each transmission and direction - but cryptographically speaking this is not required.

incr is the space reserved for the block counter used for CTR. It allows $2^{64}$ 16 byte blocks to be encrypted for each message. That should be plenty.

26 bits are left over. This is a bit weird: it would at least be easier to have IV1 and IV2 occupy their own byte. Now the least significant bits of the IV1 & IV2 byte must be set to zero and you have to shift the bits into place.

---

It is up to the protocol and protocol implementation to make sure that the IV doesn't repeat. The build up of the IV does seem to allow this.

Beware that counters are particularly dangerous to implement: a reset of the device should for instance not reset the counter value. If the implementation can be fooled to increase the counter if the transmission fails then the counter could easily cycle back to the starting value after $2^{32}$ tries.

---

TL;DR: this seems like a well thought out build up for the IV. If that IV is made sure not to repeat this scheme should deliver the security promised by CTR and AES.

Answer 3

Firstly, the construction that you described does not provide integrity. So as you say, the ciphertext is malleable.

As you suggest, if the sequence $\textrm{COUNT}||\textrm{IV}_1||\textrm{IV}_2||0^{26}||\textrm{incr}$ can be guessed by an attacker the construction is weak. An attacker with access to an oracle can recover/rebuild the stream and xor it with a given ciphertext and decrypt it.

More generally CTR mode produces a (very very) long pseudorandom key-dependent stream, and uses it to encrypt the plaintext XOR'ing the key-dependent stream with the plaintext. (this is very similar to the One Time Pad encryption, but with the random string generated by the AES)

Reusing the counter with the same key means re-generating the same key-dependent random string, breaking the OneTime property.

See also Why must IV/key-pairs not be reused in CTR mode?

You could probably give a look to the AES-SIV construction, SIV stands for Syntetic IV where the nonce is generated from the message itself, rather than being an explicit input into the algorithm. [See: RFC 5279 or original paper]