5

SHA-1 has long been considered insecure, and now the attacks have been demonstrated in practice also. The proposed alternative for SSL certificates is the SHA-2 suite of hash functions, of which SHA-512 is most commonly used.

However, the hash generated by SHA-512 is nearly 4 times longer than SHA-1. This is not a problem is the hash is used only by machines, but for e.g. verifying file integrity manually it is inconveniently long.

Question

Is there any hash function that:

  • has the same (at most) 160 bit long hash as SHA-1,
  • has been widely analyzed,
  • but has no known vulnerabilities?
Community
  • 1
jpa
  • 950
  • 6
  • 11
  • Do you consider [online text comparing](https://www.google.co.il/search?q=text+compare) inconvenient? – MiaoHatola Mar 05 '17 at 17:04
  • 5
    *"...of which SHA-512 is most commonly used..."* - this is a claim without source and I very much doubt it. – Steffen Ullrich Mar 05 '17 at 17:46
  • For verifying file integrity even sha1 is inconveniently long; I much prefer crc32. The reason to use a sha is because you want a cryptographic hash, and if you want a cryptographic hash you really want it to be secure, not sorta secure. So use a secure option and use the computer to compare hashes - they're good at that. – Xiong Chiamiov Mar 05 '17 at 18:04
  • 4
    Brute forcing a collision of a 160 bit hash takes about as much work as the bitcoin network expends on mining every two days or so. I encourage you to upgrade to 256-bit hashes. – CodesInChaos Mar 05 '17 at 20:17
  • Bitcoin miner hash SHA256 2^66 per second and 2^83 per day. 160-bit is not secure against the collision attack. – kelalaka Oct 12 '19 at 19:30
  • In addition to truncating something longer, or SHAKE (part of Keccak/SHA-3) which is variable length, RIPEMD160 has been around almost as long as SHA1 and is used in bitcoin so I'd bet it's gotten a fair bit of analysis. @kelalaka: collision is only a problem for 'file integrity' if we are responsible for attacker-chosen files, which Q doesn't say. – dave_thompson_085 Oct 13 '19 at 07:14
  • @dave_thompson_085 I don't think so. He wants to get rid of SHA-1 because it is broken. Also, ask for `has no known vulnerabilities`. I simply said that the generic collision attack with computers has surpassed the 160-bit hash output. – kelalaka Oct 13 '19 at 07:47

2 Answers2

8

First, SHA-256 is significantly faster (usually) than SHA-512, and is strong enough for the vast majority of uses.

Second, you can truncate hash output, as long as you're aware of the "birthday paradox" -- e.g. 160 bits of output gives you ~80 bits of security. You probably want to avoid truncating if possible, but if you need to, SHA-256 truncated to 160 bits is better than SHA-1 at this point.

Note that all the recent SHA-1 attacks are collision-based -- there are no preimage or 2nd preimage attacks, even against MD5, so "reversing" these aren't feasible (currently).

Community
  • 1
Scovetta
  • 335
  • 1
  • 4
  • 2
    Typically on 64-bit machines SHA-512 is faster, on 32-bit machines, SHA-256 is faster. – CodesInChaos Mar 05 '17 at 20:16
  • @CodesInChaos good point -- Also, Intel recently released hardware support for SHA-256, but I haven't seen benchmarks on it yet. – Scovetta Mar 05 '17 at 20:30
0

You drafted two different things here:

  • for SSL certificates using SHA1 for HMAC is still secure, it is unneccessary to change it (see this related publication)
  • for regular uses (e.g. integrity checking) there is no better widely used better algorithm in 160 bits. It might worth a note that depending on the algorithm, truncating a hash of more bits might still be a better option (see this topic)

This is not a problem is the hash is used only by machines, but for e.g. verifying file integrity manually it is inconveniently long.

This is not a problem, in 99.999% of the cases you can determine mismatch with your eye. Otherwise, you can compare checksums in your terminal, which is as easy as this 8 liner I just wrote you in under 30 seconds (name it sha1check.sh)

#!/usr/bin/env sh

if [ `sha1sum $1 | cut -d' ' -f1` = "$2" ]; 
then
   echo 1
 else 
   echo 0
fi

Usage:

$ sha1check.sh file.zip ffc06e14fb40db2da3ce0117b4483a8f0ca86937
0

PS: The first successful sha1 collision was published like a week ago, and its technical details are kept private. It's highly unlikely that anyone else other than Google would use this.

Community
  • 1
Rápli András
  • 2,144
  • 1
  • 11
  • 24
  • 1
    Most of the technical details of the collision attack were already published by Marc Stevens of CWI (one of the author of the paper that the Google's attack was based on) in 2013. And the actual code that's used to find the collision will be published after 90 days, following Google's vulnerability disclosure policy. – Lie Ryan Mar 05 '17 at 23:53
  • _Certificates_ don't use any HMAC and should already have stopped using SHA1 signatures last year. Older SSL/TLS _ciphersuites_ use HMAC-SHA1 for data integrity and it remains secure for that purpose, but those ciphersuites have attacks on the _encryption_ either RC4 weak by itself or CBC EtM giving padding oracles, so AEAD-not-HMAC-anything ciphersuites should be preferred. PS: 'drafted' makes no sense there; you may want 'included' or 'connected' or 'confused' or 'mixed [up]' – dave_thompson_085 Mar 06 '17 at 12:08
  • You can also pipe `grep` to check if the `sha1sum` produces the expected checksum: `sha1sum file.zip | grep ffc06e14fb40db2da3ce0117b4483a8f0ca86937` produces the expected output if the actual checksum matches the expected checksum, but produces no output if there is a mismatch. – mti2935 Jan 27 '21 at 17:29