Subject: [eap] Re: SHA-0 Broken

From: Thomas Otto <[email-masked]>
Date: Tue, 17 Aug 2004 23:53:45 +0200

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

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

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

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)

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?

Thomas 

References

[3] http://www.freedom-to-tinker.com/archives/000661.html
[4] Edward Felten is Professor at Department of Computer Sciences, 
Princeton University, his personal website is
http://www.cs.princeton.edu/~felten/
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Aug 2004 17:12:38 -0500

> underlying hash function." 

This is hardly enough to judge the situation.

> appeared - therein, he gives a general classification of this attack (excerpt 

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.

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

>    (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?

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 17 Aug 2004 16:53:04 -0700

[email-masked] wrote:
<snip>

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

[Joe] It is more likely that correct fixes to a problem will be developed
quicker and distributed faster for widely used extensible protocols than for
single use protocols that have not had their extensibility tested (or even
designed).

> 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
> seen it these days (this has been, at least, my impression). Having
> one ore more alternatives can not be a disadvantage, right?
> 
> 
> Thomas
> 
> References
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 18 Aug 2004 11:23:54 +0200

>underlying hash function." 
Can you say that if I break SHA-1, so I break TLS-PRF?

[Russ Hously] The attacks are very bad news for the use of the one-way 
hash functions in digital signatures, especially in a non-repudiation 
context.  So far, the attacks do not cause security concerns with MACs 
and PRFs.

>   (aes in eax mode, hash is OMAC)
I think the authors of new EAP methods didn't argument neither with 
CRYPTO04, nor with SHA complexity.
However, like SHA-1 was (and STILL for this moment) a complexe function 
within TLS context, AES may be one day (maybe next week) also broken.

IMHO, the solution is not to define new protocole, new shaky 
cryptographic algorithms and functions will be sufficient.

AES already used within TLS. In the contrary, TLS does not depend on AES 
itself.

TLS_..._WITH_AES_length_CBC_SHA for public key authentication
TLS_..._PSK_WITH_AES_length_CBC_SHA for PSK authentication

Neither TLS nor IKEv2 rely on a particulare cryptographic function. Even 
IKEv2 is the more generic protocol, it is not so hard to update 
cipher_suites defined by TLS with new hash functions.

>I agree. But why concentrating on one protocol? What if this protocol becomes 

I am not opposed to any protocol. Let me answer you by a question: why I 
have to create 'new' one? Why I shall create a new protocol whereas I 
already have the same services if I partially or if I simplify the use 
of IKEv2 or TLS?

Regards,

-- 
Mohamad Badra
ENST-Paris
Dept. Computer Sciences and Networks