Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 10 down vote favorite

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

Whatever, 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.

share|improve this question

migrated from stackoverflow.com Sep 28 '11 at 11:21

3 Answers

up vote 7 down vote accepted

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.

share|improve this answer
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? – Mike 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. – Jeffrey Hantin Sep 28 '11 at 0:00
1  
THAT'S the point I was looking for and the reason why CBC isn't "dead". Thanks a lot! :-) – Mike Sep 28 '11 at 0:14
up vote 3 down vote

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.

share|improve this answer
up vote 2 down vote

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?

share|improve this answer
1  
The default cipher mode in the solution you mentioned is CBC so it may have the same problem if CBC gets insecure... – Mike Sep 27 '11 at 22:44
2  
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. – David Pope Sep 27 '11 at 22:58
1  
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. – Mike Sep 27 '11 at 23:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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