Hello all, On 20/04/07 08:32, Aram Perez wrote: > The proposal for using AES128-CBC with a fixed IV of all zeros is for > a protocol between two entities that will be exchanging messages. > This is being done in a "standards" body (OMA) and many of the > attendees have very little security experience. As I mentioned, the > response to my question of why would we standardize this was "that's > how SD cards do it". > > I'll look at the references and hopefully convince enough people that > it's a bad idea.
Relating to the anger at the "random bunch of people [who] design crypto protocols": What Aram wrote is "many of the attendees have very little security experience", not: "there are no attendees with security experience". There are people at the relevant OMA group who know enough about security, but just like in the real world -- they are outnumbered by plain "feature-set" people, and thus have to come up with very clear arguments to get their way. Aram figured fixed IV's is generally a bad idea, and probably so did others at OMA, but since the security people have to build a case and not just say "well, it's generally not a good idea", a more descriptive explanation of possible attacks (a "justification") was sought for. Now to the subject matter: I do not know the protocol in question, but in a nutshell: Generally, CBC with a fixed IV (be it zero or any other value) is to be avoided for the reason described in previous posts. In some circumstances this restriction may be relaxed, such as: (1) if the first unknown (to the attacker) block _always_ follows (not necessarily immediately) a session-specific block (a block that is not likely to repeat for the same key, such as a message-id). For example, if every encrypted structure starts with an id that never repeats among structures, and all "security-wise meaningful" blocks follow it, you are _probably_ safe. (2) if the key is never re-used among structures you encrypt. AND (3) If you don't care about replacement attacks on the (1 to i) blocks that will result only in a (possibly-undetected) corruption when decrypting the i+1 block (rather than two blocks, with a varying and non-attacker-changeable). For example: If Message #1 and Message #2 are encrypted with the same key, you can take blocks 1,2,3,..,i of Message #2 and paste them in Message #1, and only block i+1 will decrypt badly. If you had protected (attacker unchangeable) and varying IV's, block 1 would have decrypted badly too, for whatever it's worth. (Comment: block 1 can be any higher index, as long as there are no earlier blocks that differ between the messages.) As the others stressed: the implication of these conditions/limitations, as well as others which I may have not spotted, depend on the protocol... Hagai. P.S. Aram, as you know, I am signed on the OMA NDA, so you can send me the protocol. If other members here are signed on the OMA NDA, I guess it could be useful if you notified Aram in a private message, so you can get your copy and examine it too. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]