5

I recently came across an application that more or less does this:

  • starts from a (supposedly unknown to others) key
  • generates a random IV
  • encrypts some smallish (~ 160 bytes) payload with the key and generated IV using AES256 in CBC mode
  • [>=60% of payload is comprised of two or three ASCII words, chosen from a supposedly unknown but more or less easily guessable list of some dozen elements]
  • derives another IV just by doing some math on the key. This IV will be the same for every packet, ever, and the code to generate it from the key is publicly known.
  • encrypts a small header (32 bytes) with the key and derived IV using AES256 in CBC mode
  • [most of this header is made of fixed data such as "protocol version" that should be considered publicly known, then it contains a unix timestamp (known data if you know when the packet has been transmitted) and the random IV used before for the payload part]
  • transmits the resulting encrypted header+payload on the wire

The receiving part knows the (pre-shared) key, regenerates the "header IV" from that, decrypts header, gets payload IV from there, decrypts payload.

The whole stuff repeats for every packet, and the typical application would have anything from 5 to 50 packets per second going on the wire, and since many of them are just "status info" the only difference between their cleartext would be the unix timestamp and the (pseudo)randomly-generated payload IV.

I'm definitely no cryptography expert but as far as I know "fixed IV derived from key used to encrypt 32 bytes, 28 of which are fixed and/or easily guessable" should at least ring some alarm.

How could the security of such approach be considered? - "security" defined as keeping the key and/or the payload secret even if someone could eavesdrop packets from the wire.

4

Consequences of an IV reuse range from "serious" to "dramatic", depending on the encryption mode. AES, by itself, is a block cipher: it processes blocks of 128 bits. When encrypting a message (with a length other than exactly 16 bytes), one must use a block cipher mode of operation. Many such modes are "sequential" in some way, with a running state, and the IV is the initial value for that state.

If the encryption mode is CTR (as is common in many modern extended modes like GCM), IV reuse is deadly, because then the encryption degrades to the infamous multi-times pad. With CBC mode, IV reuse is somewhat less critical, yet serious. In particular, a reused IV is also, by definition, a predictable IV, which can be leveraged in chosen-plaintext attacks like the BEAST attack.

A more general comment is that a reused IV is a sign of incompetence; it is unlikely that the said incompetence stopped at the IV reuse. Chances are that other elements of the whole protocol are similarly poorly designed. Weaknesses don't travel alone...

  • Thanks for your explanation. AES is actually run in CBC mode, I added that to my question. Part of the header (which is encrypted with the same IV in each and every packet) should be considered known-plaintext because there are some fields that almost never change (protocol version and other related flags). – Luke404 Jul 15 '14 at 23:18
1

What you have explained sounds similar to WEP encryption for 802.11. I am not a cryptologist either, but have read through the Aircrack-ng docs quite a few times. Using this encryption technique for a static data set opens the application to statistical based attacks such as Korek and FMS. A deep explanation of how these attacks are done on WEP can be found here. And there are a lot more resources that can be found here which explain other attacks on the 802.11 encryption protocols.

0

I'm no expert either, but from what I understand, the actual payload is encrypted with a random (supposedly unique) IV for each packet, which is the right way to do things. It doesn't matter that the payloads are very similar.

The header, on the contrary, is very susceptible to attacks (see this question for a more thorough explanation), but since it's public data anyway, I don't believe that this is a problem: the AES key can't be recovered from known ciphertexts as far as I know.

My primary concern is that the fixed IV is generated through nondescript "math" performed on the key. Depending on what actually happens here, some information may be leaking about the key and you really don't want that.

To sum up, this is definitely not the standard way to do things, and the way the header is encrypted seems highly insecure to me. Is it insecure enough to reveal the contents of the payload as well? Maybe, we'd need more information to tell. The payload encryption looks sound to me though. How about keeping things simple? If this header really is made of public data, it shouldn't be encrypted and in any case, it doesn't make sense to use different IVs for the header and the payload. Either use the random IV for the whole packet, or don't encrypt the header (and ditch that fixed IV)!

  • Thanks for your explanation. I'd just add that I came across this thing but I did not write and cannot modify it :) AFAIK the header is encrypted mostly to guarantee (?) that the sender knows the pre shared key and to send the payload IV not in cleartext. – Luke404 Jul 15 '14 at 23:16
  • Well, the IVs are meant to be sent in cleartext... Just in case you have a chance to interact with the authors! – executifs Jul 16 '14 at 7:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.