On Sun, Feb 26, 2012 at 1:46 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Sat, Feb 25, 2012 at 10:47 PM, Kevin W. Wall <kevin.w.w...@gmail.com>
> wrote:
>>
>> [SNIP]
>>
>> Thanks for the link. It took me a LONG time to convince the ESAPI team
>> of this because I was the newb to them and I came in and said we
>> need to at least need to add a MAC over the IV+ciphertext. But it
>> took me a really long time to convince them because I could not remember
>> Vaudenay's name (so sorry if you are out there reading this!) and neither
>> could I recall the details of how it was done. I finally stumbled upon
>> it while Googling for cryptographic attacks against IPSec, which I remembered
>> was one of the things originally affected.
> Also of interest is Wagner and Schneier's "Analysis of the SSL 3.0
> protocol" from 1996 or so (www.schneier.com/paper-ssl.pdf). The Horton
> Principal (Semantic Authentication) tells us to validate the IV and
> Ciphertext. From the contrapositive: if there's no need to validate
> the IV or ciphertext, then there is no need to send it because it has
> no value. I often use the contrapositive to flush out useless junk in
> a protocol.
Here's a perfect example of a violation of Wagner and Schneier's
Horton Principal: Support of Non-Canonicalized Messages in EAX' (used
in the US Smart Grid) [1]:
Hardware non-support of canonicalized messages: Some
modem chips such as many of those for IEEE 802.15.4
provide hardware support for CCM-mode transmission
and reception when the message to be CCM-authenticated
consists exactly of the message Cleartext and plaintext, in
that order, that is to be sent or that was received. However,
ANSI C12.22 requires that the authenticated message use
canonical forms of ApTitles, and exclude the
<calling-AP-title-element> (the ApTitle of the message
originator) when it was added by a proxy C12.22 Relay. The
resultant software-based sequencing of invocations of the
underlying hardware block cipher (e.g. AES-128)
implementation is equivalent to that required for EAX.
Either <calling-AP-title-element> has value and it gets MAC'd; or it
has no value and it is not even sent. Here, ANSI finds refuge in a
bastard world where it claims <calling-AP-title-element> has value but
it is not MAC'd. This means <calling-AP-title-element> will be forged
in the field by the attacker.
Jeff
[1]
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/eax-prime/eax-prime-spec.pdf
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
