15

I developed a p2p-app in C# which sends and receives encrypted text messages (50kB). For encryption, my app uses 128-bit AES in CBC cipher mode. For each message it uses a new randomly-generated IV.

However, after reading the following two publications, I have some concerns about my solution:

I'm not an expert in encryption so my question is very simple: Do I have to replace CBC with another cipher mode or is it still secure in my scenario?

Since my app uses the RijndaelManaged class in C#, my alternatives are: CFB, CTS, OFB.

Patriot
  • 3,132
  • 3
  • 18
  • 65
Mike
  • 315
  • 1
  • 8
  • The accepted answer to this question doesn't appear to specify a cipher mode at all. It uses the defaults, which in my experience is the best thing to do for anything crypto-related unless you are very clear on what you are doing and why you are doing it. Is there a reason you believe you need to specify a cipher mode? –  Sep 27 '11 at 22:27
  • The default cipher mode in the solution you mentioned is CBC so it may have the same problem if CBC gets insecure... –  Sep 27 '11 at 22:44
  • In that case you can bet that MSFT will address the problem, either by deprecating the old class and replacing with a new one (probably) or by changing the default (less likely). Nailing it down in your own code makes it less likely that you'll benefit from any improvements they make to the default path. Note that I'm not saying that it's somebody else's problem -- I'm saying that crypto is hard, and getting it right can be a very deep rathole. I find it better to leverage the work of those dedicated to the problem than to roll your own, unless you have specific needs. –  Sep 27 '11 at 22:58
  • Thanks for that additional information. My problem is, that my app communicates with apps written in other languages and environments. If I change the cipher mode in C#, I have to change it in all other apps too. –  Sep 27 '11 at 23:20

2 Answers2

13

The attack is due to predictable initialization vectors. If you're using a new random IV for each message the attack doesn't apply.

In pre-1.1 versions of TLS, each record's IV is the last ciphertext block of the previous record; this can be used to influence the IVs used by the server.

This is fine within a message, but the problem comes when you continue to chain cipher blocks from one message to the next.

Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
  • 1
    ok, thanks for your answer but: I'm using a block size of 128 bit which means (as I understand...) if my app encrypts a message with a size of 50KB, it splits it into 128-bit-pieces and uses the IV of the last ciphertext block. I'm I wrong? –  Sep 27 '11 at 23:06
  • 2
    @Mike, the problem comes when you continue to chain cipher blocks from one message to the next, not when you chain them within one message. –  Sep 28 '11 at 00:00
  • 1
    THAT'S the point I was looking for and the reason why CBC isn't "dead". Thanks a lot! :-) –  Sep 28 '11 at 00:14
11

The flaw in CBC which the recent BEAST attack exploits occurs when the attacker can choose part of the encrypted message while knowing the IV which will be used. In the case of SSL/TLS, data is split into successive records, each record being "a message" in its own right. The attacker produces some data, observes the corresponding record, and knows that the last block of that record will be used as IV for the next record.

The issue does not occur if each "message" is encrypted with a newly generated IV, such that the IV generation process is unpredictable by the attacker. This is what newer versions of TLS do (beginning with TLS 1.1), and they are quite happy with CBC, which is no deader than Disco.

Thomas Pornin
  • 86,974
  • 16
  • 242
  • 314