Recently, there was a paper of an attack against SHA1 and its usage as a long lived cryptographic hash for digital signatures and file verification. (https://en.wikipedia.org/wiki/Cryptographic_hash_function).
To help garnish more hype, the research findings were named “shattered” and they put up a web site: shattered.io
This being said, it does make it easier to find the information but I do have a few complaints about the hype and melodrama at their website.
“We have broken SHA-1 in practice.” when in reality, what is broken is SHA-1 for digital signature and other long lived hashing verification; there are still many usages of SHA-1 that are safe.
From their paper’s abstract “SHA-1 is a widely used 1995 NIST cryptographic hash function standard that was officially deprecated by NIST in 2011 due to fundamental security weaknesses demonstrated in various analyses and theoretical attacks.” Again, SHA-1 for digital signatures was deprecated but just nit picking here…
Again, from the paper, “As a result while the computational power spent on this collision is larger than other public cryptanalytic computations,”
Does this mean there are computationally less expensive attacks? If so, what is then novel about this paper other then they named their attack and put up a cool web site? After a bit of digging, it looks like the less expensive options required certain pre-conditions that may not be readily available in real world scenarios.
What are the implications beyond digital signatures and other long lived cryptographic verification?
I am fairly certain TLS and DTLS SHA1 is safe since the Hash then Encrypt structure (the hash is encrypted) of xTLS protects the hash from modification. The hash is encrypted; thus, without the key, an attacker cannot modify or even read the value. There is no opportunity for a collision attack. https://en.wikipedia.org/wiki/Transport_Layer_Security
Since IPSec encrypts and then does an HMAC, the HMAC is exposed in the clear unlike xTLS. The HMAC is also used to protect the ESP header which includes the IPSec packet sequence number. IPSec uses an incrementing sequence number to prevent attackers from injecting older messages into the stream of packets. If one wanted to modify the sequence number, they would need to also modify the HMAC such that a check of the HMAC would indicate the packet is safe.
IPSec’s HMAC is exposed unlike xTLS, but is still probably safe for now as long as the IKE rekey sequence is anything sane. IPSec will negotiate a new session key between the sender and receiver utilizing a protocol referred to as IKE; this also resets the sequence number.
From my quick digging, it looks like the Linux default ikelifetime value is 8 hours with a maximum of 24 hours. Since the attack still requires multiple days to achieve and because of the short-lived nature of the packets, (The attack still requires 2^63 checks) IPSec is probably safe. Additionally, the shattered attack requires the ability to manipulate some of the hashed data so as to create a collision. The ESP packet field does not offer many places to do this and altering the encrypted data section would corrupt the underlying information.
I think IPSec is safe for now… I assume the same holds true for SSH.
Passwords: This gets interesting as the paper outlines a collision technique. The idea would be to generate a password/string (could be the same or not) that combined with the salt would generate the same hash as stored in a system. What I don’t understand is the mutli-iterations used by PBKDF2 effects on the collision technique. When passwords are stored, each is combined with a unique string and then hashed multiple times (10,000+) to increase the work factor if someone attempts to break them. I do not think they have yet published the math behind the attack and it is a bit beyond my time budget to understand, so I am not sure.
This being said, here is a quick summary of the brute force cracking capabilities for a NVidia GTX 1080
SHA1: ~15,400 MH/s
SHA256: ~2,870 MH/s
SHA512: ~1080 MH/s
https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40
And a single core on a Intel Core i7 4960X:
SHA1: ~568 MH/s
SHA256: ~229 MH/s
SHA512: ~333 MH/s
It is interesting to note that on x64 system, SHA512 is faster than SHA256.
https://wiki.openwrt.org/doc/howto/benchmark.openssl
Given the speed difference in GPUs and CPUs and the desire to increase the work factor to help prevent brute force attacks, SHA512 should be used in multi-iteration hash functions like PBKDF2 to protect passwords even if SHA1 is still safe.