eap Mailing List: Re: Re: SHA-0 Broken

[Nicolas Williams (Nicolas.Williams]

On Tue, Aug 17, 2004 at 11:53:45PM +0200, Thomas Otto wrote:
> Mohamad Badra wrote: 
> > Add to that, if SHA-1 will be broken, this does not mean that HMAC_hash
> > is automatically broken since TLS-PRF uses HMAC_hash instead of hash. 
> 
> A short look in the abstract of RFC 2104, HMAC, shows us the relation:
> "The cryptographic strength of HMAC depends on the properties of the 
> underlying hash function." 

This is hardly enough to judge the situation.

> 
> Jari Arkko wrote:
> > The slides you pointed us to say "the technique is not applicable to full 
> > SHA-1". 
> 
> This is the state-of-the-art. What about tomorrow, next week or next month?
> Along with the slashdot.org announcement, a statement of Edward Felten 
> appeared - therein, he gives a general classification of this attack (excerpt 
> of [3])

And it could be that SHA-1 is stronger against finding messages that
hash to a given value than we think in spite of the collision finding
results.  We don't know.  Making decisions in this environment is not
easy.

> > The finding of a single collision in SHA-1 would not, by itself, cause much
> > trouble, since one arbitrary collision won't do an attacker much good in
> > practice. But history tells us that such discoveries are usually followed by
> > a series of bigger discoveries that widen the breach, to the point that the
> > broken primitive becomes unusable.
> 
> I'd like explicitly state that I'm aware of the fact, that this is the EAP 
> mailing list and not a cryptography mailing list and that I immediately
> stop talking about crypto topics. 
> Nevertheless, most of us are certainly no designated experts in the
> cryptography area and are reliant on research results of *real* cryptographers
> like him. And why not take their advises into account? 
> 
> At this point, the question might arise: Why this discussion thread is 
> initiated? This is because of the recent discussion about PSK methods. On 
> August 6th, M.Badra posed the question
> 
> > Why we need (the goal) to define new pre shared key methods, that 
> > are NOT based on TLS or IKEv2.
> 
> To tell the truth: Because of events like that at Crypto 04. Why not having
> alternatives which does not rely on TLS, and much more, which makes use of
> completely other cryptographic primitives than all proposals before? 

Well, the off-the-shelf technology you're arguing should be avoided has
room for extensibility and replacing ciphers and MACs.

> Have a look at EAP-PSK: This is an EAP method which is based on a pre-shared
> key and takes as underlying crypto primitive AES. Nothing more, just AES.
> More precisely, AES-128 is used for
> * mutual authentication 
> * session key derivation (via modified counter mode)
> * encrypted communication through the secure tunnel 
>    (aes in eax mode, hash is OMAC)

And what if AES is broken tomorrow?  Inpractical attacks exist, but do
they cast a shadow on AES' future?

Why EAX?  Why not GCM?

> Let me enumerate some EAP methods which use a PRF function based on the 
> hash functions currently came under fire: 
> EAP-TLS and EAP-PAX on the one hand (TLS-PRF), 
> on the other hand PEAPv2, EAP-FAST  (PRF of IKEv2)
> 
> Second, Joe Salowey mentioned that
> 
> > [...] methods based on existing key exchange frameworks such as TLS and
> > IKEv2 are valuable because they build on widely implemented (at least in the
> > case of TLS) and reviewed standards. TLS is probably the most widely
> > deployed one and it has been extended to support multiple mechanisms 
> > including certificates, kerberos and pre-shared key.  I would prefer to
> > focus on the standard frameworks first. 
> 
> I agree. But why concentrating on one protocol? What if this protocol becomes 
> vulnerable?
> 
> To sum all up: The intention is the conclusion that it is possibly best 
> practise to allow some kind of heterogeneity in development, and to treat 
> proposals which are not main-stream a little bit more tolerant than we have 
> seen it these days (this has been, at least, my impression). Having one ore 
> more alternatives can not be a disadvantage, right?

I, for one, am not ready to conclude that.  Methinks it's still too soon
since the announcement of these collision findings to make rash
decisions.

Cheers,

Nico
--