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.


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?
  • Do you consider online text comparing inconvenient? – MiaoHatola Mar 5 '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 5 '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 5 '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 5 '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

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

| improve this answer | |
  • 2
    Typically on 64-bit machines SHA-512 is faster, on 32-bit machines, SHA-256 is faster. – CodesInChaos Mar 5 '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 5 '17 at 20:30

personally i just truncated a 512bit blake2b to 160 bits, with blake2b being faster than MD5, SHA-1, SHA-2, and SHA-3 for amd64 and ARM processors, and having a security margin comparable to SHA-3 (and it's predecessor BLAKE was a SHA3 finalist along with the SHA-3 winner Keccak), it's an excellent replacement for SHA1 imo.

btw i did some birthday collision math, with 2^64 samples (18.4 quintillion samples, meaning enough samples to exhaust unsigned 64bit id space), the chance of getting a single collision via the birthday paradox with 160 bits hash should be approximately 0.00000001164%

| improve this answer | |
  • 1
    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:21
  • @kelalaka interesting, btw blake is relatively resistant to ASIC implementations, compared to the other SHA3 finalists, blake was by far the slowest in hardware implementations (while being the fastest in software implementations), some explanation for that can be gained from blake2.net which states BLAKE2 is fast in software because it exploits features of modern CPUs, namely instruction-level parallelism, SIMD instruction set extensions, and multiple cores. - which did not translate well to hardware (that wasn't why BLAKE lost, but NSA wanted something fast in hardware) – user1067003 Oct 12 '19 at 19:25
  • 1
    Also, the Shake series are designed for arbitrary output. See the resistance of trimming here – kelalaka Oct 12 '19 at 19:30
  • @kelalaka speaking of, blake2b is actually a variable-length algorithm "producing digests of any size between 1 and 64 bytes", but benchmarks showed that (for my application) it was faster to calculate the full 64 bytes and truncate it to 20 bytes, than to calculate the 20 bytes version.. guessing the (de-facto) 64 byte codepath was more optimized? also blake2 has it's own arbitrary output size version called blake2x, but i've never tried it myself ^^ ... never really seen or heard of anyone using blake2x either – user1067003 Oct 12 '19 at 19:47
  • Thomas's article. Blake2 site cannot be a reference! – kelalaka Oct 12 '19 at 20:00

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" ]; 
   echo 1
   echo 0


$ sha1check.sh file.zip ffc06e14fb40db2da3ce0117b4483a8f0ca86937

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.

| improve this answer | |
  • 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 5 '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 6 '17 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.