[Openvpn-users] Schneier saying that SHA1 has been broken

[James Yonan]

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

While OpenVPN uses SHA1 extensively (as does SSL/TLS and most other
cryptographic software in existence today), there's probably no need to
panic yet because the breakage doesn't appear to affect the HMAC-SHA1
construction or other less collision-sensitive applications.

In any case, OpenVPN is flexible enough that you can choose any other
secure hash supported by OpenSSL using the --auth directive. SHA1 is the
default, but it's not hardcoded. SSL/TLS may be another story though.

James

[Andreas Iwanowski]

I'm not a crypto expert, but how does this affect an OpenVPN implementation using SHA1?

Thank you for informing us about that.


-andy

-----Original Message-----
From: James Yonan [mailto:***@yonan.net]
Sent: Wednesday, February 16, 2005 4:50 AM
To: openvpn-***@lists.sourceforge.net
Subject: [Openvpn-users] Schneier saying that SHA1 has been broken


http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

While OpenVPN uses SHA1 extensively (as does SSL/TLS and most other
cryptographic software in existence today), there's probably no need to
panic yet because the breakage doesn't appear to affect the HMAC-SHA1
construction or other less collision-sensitive applications.

In any case, OpenVPN is flexible enough that you can choose any other
secure hash supported by OpenSSL using the --auth directive. SHA1 is the
default, but it's not hardcoded. SSL/TLS may be another story though.

James



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Richard Atterer]

There is no need to panic, folks!
My attempt at explaining this in understandable terms:

SHA-1 has indeed been broken, but "broken" in the academic sense: Someone
has found a more efficient algorithm to defeat SHA-1 than trying out all
possibilities.

A brute-force SHA-1 attack (trying out all possibilities) needs 2^80 tries.
According to Schneier, the new approach reduces this to 2^69. This means
that to "crack" a single OpenVPN session which relies on SHA-1, someone
would need to repeat certain operations 2^69 times. This is an incredibly
high number, and well beyond the capabilities of any computer on this
planet.

Furthermore, I'm not sure whether the published attack applies at all to
the way that SHA-1 is used with OpenSSL (used by OpenVPN). With many
applications, so-called "collision" attacks (the easier type of attack, and
AFAIK the type Schneier talks about) are not applicable. I'm not sure, but
it is quite likely that the attack is not applicable to OpenSSL.

On top of all that, these "academic" cryptographic attacks are often much
more complicated than a brute-force attack, with the result that it's
actually faster to do the full, simple 2^80 attack than the convoluted 2^69
attack. (There is a possibility that the new attack can be optimised
further, so an eye needs to be kept on this issue.)

In a nutshell, for all practical purposes, your OpenVPN connection is as
secure today as it was yesterday. There are much weaker links in the whole
system - for example, when did you last check that all software on the
OpenVPN server is free of all known security holes? How about that backup
of the VPN server's certificate which is lying around on your office desk?
;-)

As for alternatives, I must say that so far I thought that SHA-1 was the
best hash code that is available. :-| I believe the folks who cracked it
are not going to make the details of their approach public knowledge in the
nearer future - once that has happened, people will be able to design
stronger hash algorithms which will not be vulnerable to this kind of
attack.

HTH,

Richard

[Mathias Sundman]

Post by Richard Atterer
As for alternatives, I must say that so far I thought that SHA-1 was the
best hash code that is available. :-|

Was? Is there now a better alternative, apart from the obvious SHA-256,
SHA-384 and SHA-512 (that is supported by OpenSSL)?

[Richard Atterer]

Post by Mathias Sundman

Post by Richard Atterer
As for alternatives, I must say that so far I thought that SHA-1 was the
best hash code that is available. :-|

Was? Is there now a better alternative, apart from the obvious SHA-256,
SHA-384 and SHA-512 (that is supported by OpenSSL)?

There is none (that I know of). Read this sentence as "I used to think that
SHA-1 is best. Now that it's broken, I don't think it's a good choice."
Unfortunately, there isn't really any alternative. :-/

Cheers,

Richard

[Whit Blauvelt]

Post by James Yonan
In any case, OpenVPN is flexible enough that you can choose any other
secure hash supported by OpenSSL using the --auth directive. SHA1 is the
default, but it's not hardcoded. SSL/TLS may be another story though.

Does anyone have a recommendation from among the alternatives? Do any of
them have platform-specific issues? Is one of them cryptographically sexier
than the rest, by present reputation?

Whit

[Charlie Hosner]

IMHO, this is a major news item, but does not warrant any action on any
administrator's part today.

The Schneier letter cited that SHA1 has been broken down to 2^69 strength.
I have not yet looked over the paper itself as it is not public, but just
for reference, MD5 only provides 2^64 strength (pre-weakening), so weakened
SHA1 is still a good option. 2^69 is still beyond our ability to brute
force. I repeat, no one has been able to publicly test a key space as large
as 2^69 in polynomial time. Additionally, as James pointed out, the
hmac-sha1 construct is not affected by this so you are still safe using it.
Collisions are not a big deal when you are appending a key to the front of
the message.

The real concern here is that SHA1 is starting to leak, and will most likely
continue to leak. You can expect the see the 2^69 key space shrink over the
next few years. So, today, I don't think you need to do anything. However,
it is past time for the community to get serious about developing a new hash
algorithm. Another AES type contest sounds like just the thing we need.

For alternatives, in the near term you can look to SHA256,SHA384,SHA512.
They will stretch out the key space and prolong the inevitable demise of the
SHA-like algorithms, by a good bit. Hopefully these will show up in TLS
sooner rather than later, but to be clear, they will be weakened by these
techniques as well. Remember thought, weakening something to 2^100 does not
render it unusable. We are still not able to brute force anything near that
size with current technology.

This is a big news item in the world of cryptography, but it is a small news
item in the world of everyday practical security.

Charlie


-----Original Message-----
From: openvpn-users-***@lists.sourceforge.net
[mailto:openvpn-users-***@lists.sourceforge.net] On Behalf Of Whit
Blauvelt
Sent: Wednesday, February 16, 2005 9:21 AM
To: openvpn-***@lists.sourceforge.net
Subject: Re: [Openvpn-users] Schneier saying that SHA1 has been broken

Post by James Yonan
In any case, OpenVPN is flexible enough that you can choose any other
secure hash supported by OpenSSL using the --auth directive. SHA1 is the
default, but it's not hardcoded. SSL/TLS may be another story though.

Does anyone have a recommendation from among the alternatives? Do any of
them have platform-specific issues? Is one of them cryptographically sexier
than the rest, by present reputation?

Whit


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Openvpn-users mailing list
Openvpn-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005

[Eugen Leitl]

Post by Charlie Hosner
For alternatives, in the near term you can look to SHA256,SHA384,SHA512.

Speaking of which, any VIA Nehemiah folks here? Anyone succeeded with
building OpenSSL with Nehemiah AES support?

nitrogen:~# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 1199.969
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr sep mtrr pge cmov pat mmx fxsr sse
rng rng_en ace ace_en
bogomips : 2375.68

But, alas:

nitrogen:~# openssl engine
(dynamic) Dynamic engine loading support
(cswift) CryptoSwift hardware engine support
(chil) nCipher hardware engine support
(atalla) Atalla hardware engine support
(nuron) Nuron hardware engine support
(ubsec) UBSEC hardware engine support
(aep) Aep hardware engine support
(sureware) SureWare hardware engine support
(4758cca) IBM 4758 CCA hardware engine support

do I need an OpenSSL version from CVS, or is there a tarball for AES support
already?

[Adi Kriegisch]

Post by James Yonan
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
While OpenVPN uses SHA1 extensively (as does SSL/TLS and most other
cryptographic software in existence today), there's probably no need to
panic yet because the breakage doesn't appear to affect the HMAC-SHA1
construction or other less collision-sensitive applications.

quoting from Bruce Schneiers Blog (see link above):
| "collisions in the the full SHA-1 in 2**69 hash operations, much less than
| the brute-force attack of 2**80 operations based on the hash length."

Now quoting from a comment of "Randell Jesup" further down the same page:
| "That's 2**11 less operations. Let's say breaking this (2**69 ops) takes the
| NSA a week. If it had been 2**80, it would have taken 2048 weeks, or 39
| years. If it would have taken the NSA (or whomever) a year to break SHA-1
| before, it could be broken in 4 hours.
|
| My guess would be it would still take a lot longer than a week - but would
| now be in the realm of possibility, whereas before it would have been in the
| lifetime(s) range. However, this is totally a wild-assed-guess, based on the
| assumption that it was expected to take 100+ years before this to crack."

Broken in a cryptographic sense means: cannot keep up to what was promised;
still 2**69 does not mean you might read it in plain text. In fact you are
far from that! It just means the promised 2**80 variations are now reduced to
2**69 because of a collision in the hash function. So this is considered to
be "broken".

But now for OpenVPN: OpenVPN uses HMAC with SHA-1 and this is considered to be
still secure. For a simple reason: it uses a key as well. This key is --
collision or not -- not guessable!
Quoting "Mike"'s comment from the same blog:
| "I'm not a cryptographer but to those who want to know why HMAC use of a
| hash function is not broken, it's because, as somebody else suggested, of
| the key.
|
| With a digital signature all you have to do is find another blob of data
| which hashes to the same hash. You are free to choose any blob of data.
|
| With HMAC you are not free to choose any other blob of data because a secret
| key is always added to the data before it is hashed and you don't know that
| secret key. So you still need to guess the key or the person verifying the
| HMAC will get a different hash than you."

And finally quoting from http://openvpn.net/security.html:
| "HMAC, encryption, and decryption functions are provided by the OpenSSL EVP
| interface and allows the user to select an arbitrary cipher, key size, and
| message digest for HMAC. BlowFish is the default cipher and SHA1 is the
| default message digest."
This is basically what was mentioned above: SHA-1 used for HMAC is at no
danger.

Conclusions:
(1) HMAC SHA-1 is NOT broken (and there is no need to look for an alternative)
(2) SHA-1 -- if the paper is right -- is considered to be broken in a
cryptographers sense.
(3) There is a need for a new standardized hash function but no need for
panic actions: 2**69 possible variations can be considered safe.
(4) Nothing changed on the security level of OpenVPN

best regards,
Adi Kriegisch

PS: Still, there exist a lot of other hash functions that are not broken
yet... ;-)