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

[Mohamad Badra (badra]

Thomas Otto wrote:

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

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

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