Hi David,
On Apr 21, 2007, at 2:04 PM, David Wagner wrote:
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.
As Hagai stated, welcome to the "real world". There may be standards
organization (IETF?) that do really worry about security, but in the
"real world", dead lines and existing products unfortunately
influence security decisions.
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?
You're totally correct but it doesn't change the "reality" of the
situation. Later this week I will create a document with the
arguments sent to me and others from papers on the web and send it to
this working group of OMA so there will be an "official record" of my
objection to the decision.
[snip]
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.
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:
1) Do a Mutual Authentication with Key Exchange
A --> B CertChainA | ControlOptions
B --> A CertChainB | E[PubA, RanB | ControlOptions |
ChosenOptions] //Using RSA-OAEP
A --> B E[PubB, RandA | H[RanB]] //SHA-1
B --> A H[RanA | RanB]
The ControlOptions includes protocol version and encryption algorithm.
2 ) Using a KDF, derive an AES-128 session encryption key SK, an HMAC-
SHA-1 message integrity key MK and either a counter or IV
Either AES-CTR or AES-CBC will be support
3) Data needing confidentiality is encrypted with the SK in the mode
selected in step 1. The message is integrity protected with MK. A new
MK is generated after a message is sent using MK(i+1) = H[MK(i)]
Hope this clarifies things somewhat.
Thanks for the replies,
Aram Perez
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
