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?
Improve this question
7
  • Do you consider online text comparing inconvenient?
    – MiaoHatola
    Mar 5, 2017 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, 2017 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, 2017 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, 2017 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, 2019 at 19:30

2 Answers 2

Reset to default
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).

Improve this answer
2
  • 2
    Typically on 64-bit machines SHA-512 is faster, on 32-bit machines, SHA-256 is faster.
    – CodesInChaos
    Mar 5, 2017 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, 2017 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.

Improve this answer
3
  • 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, 2017 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, 2017 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, 2021 at 17:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .