More info in my AES128-CBC question

[David Wagner]

Hagai Bar-El writes:
>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.

So the people who don't know anything about security are reluctant to
listen to those who do?  That's not a good sign.  It may be standard
operating procedure in groups like this, but that doesn't make it right.
It's still dysfunctional and dangerrous.  If the committee doesn't have
a commitment to security and is reluctant to listen to the experts,
that's a risk factor.

If you're sick and you go to a doctor, do you tell the doctor "you'd
better come up with some very clear arguments if you want me to follow
your advice"?  Do you tell your doctor "you'd better build a strong case
before I will listen to you"?  I would hope not.  That would be silly.
Doctors are medical professionals with a great deal of training and
expertise in the subject.  They can speak with authority when it comes
to your health.  So why do people with no training in security think
that they can freely ignore the advice of security professionals without
any negative consequences?


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

Right.

>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). [...]

Wait a minute.  This reference to replacement attacks has me concerned.  
Does the protocol use a message authentication code (MAC)?  I hope so.
If your protocol uses a MAC, and uses it properly, then replacement
attacks are not an issue, and the only issue with using a fixed IV is 
related to confidentiality.  If you don't use a MAC, you've got bigger
problems, and even random IVs won't be enough.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com