[cryptography] Explaining crypto to engineers (was: Duplicate primes in lots of RSA moduli)

Jeffrey Walton noloader at gmail.com
Sun Feb 26 14:18:40 EST 2012

On Sun, Feb 26, 2012 at 1:46 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Sat, Feb 25, 2012 at 10:47 PM, Kevin W. Wall <kevin.w.wall at 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.


[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/eax-prime/eax-prime-spec.pdf

More information about the cryptography mailing list