If a hash algorithm has an option for selecting the output-hash-length (e.g., 128 vs. 512 bits), and all other aspects of the hash function are the same, which hash-length is probably more secure/useful, and why?

  • 9
    "more secure" does not necessarily mean "more useful".
    – pipe
    Commented Apr 17, 2017 at 23:41
  • 1
    For what kind of purpose ? Passwords, files, others ?
    – Walfrat
    Commented Apr 18, 2017 at 7:29
  • 7
    Infinite hash length provides infinite security (and zero usefulness). Commented Apr 18, 2017 at 10:37
  • 3
    zero length hashes provides no security and zero usefulness :) Commented Apr 18, 2017 at 13:55
  • 2
    @DmitryGrigoryev I have an infinite-length hash: encode the file size as a 7+1-bit number, where the presence of the +1 bit means that the size contains another byte in the same 7+1-bit format. After the file size is the file contents, then is an infinite checksum. This has zero security if the database is breached in addition to zero usefulness, and being an infinitely big burden! :-)
    – wizzwizz4
    Commented Apr 18, 2017 at 18:22

5 Answers 5


How Hashes work

The concept behind hashes is very simple: take a message of arbitrary size, and deterministically produce a random-looking output of a given size. For a well-built cryptographic hash function, the only way to break it is to try random inputs until you get the hash value you want (collision or pre-image, etc).

Which is more secure?

All other thing being equal (ie it's the same algorithm, just with a different output size, ex.: SHA2-224 vs SHA2-512), then the larger the output of the hash, the more secure it is. Reason: if you have a 224-bit hash, then you expect an attacker to have to make 2223 guesses (on average) to break it, whereas a 512-bit has requires the attacker to make 2511 guesses (on average).

Which is more useful?

This one I can't answer for you, it depends on a lot of factors about the application that's using it. For example, whether you have memory, bandwidth, or processing constraints, whether you are able to easily upgrade your infrastructure if the 128-bit hash gets deprecated or if the solution you're setting up needs to be future-proof for 10 years, etc. With only the information you've given, I can't answer this for you.

  • 4
    Note that the result of a hash function doesn't have to be random-looking if all you're interested in is minimizing collisions for output of a given size. In some languages, non-cryptographic hashing of integers will map those integers smaller than the output size to themselves. Seeming randomness is only necessary for cryptographic hashing (which, admittedly, is the type of hashing the question is asking about).
    – JAB
    Commented Apr 17, 2017 at 20:09
  • 5
    All the energy in the sun can only count up to about 190-200 bits, so assuming there are no vulnerabilities in the hash algorithm, more bits are pointless.
    – Nick T
    Commented Apr 17, 2017 at 20:33
  • 4
    This only works for well-designed algorithms: I have a hash algorithm that can output 256, 512, 1024 or 2048 bits. The first 256 bits of the output are the SHA256 hash of the input, and the rest are a copy of the input padded with zeros. Which length is more secure? Commented Apr 17, 2017 at 22:28
  • 3
    @NickT that link is about encryption, not hashing. In Schneier's book Applied Cryptography, he gives the guideline that for a perfect hash algorithm a n bit hash collision can be achieved with 2^(n/2) work with a birthday attack, therefore if you want 128 bits of security you should use at least a 256-bit hash.
    – MikeFHay
    Commented Apr 18, 2017 at 10:36
  • 3
    @Martijn Does Amount of simple operations that is safely out of reach for all humanity? meet your needs?
    – user
    Commented Apr 18, 2017 at 10:59

The longest hash is the most secure since the probability of randomly finding a collision is lower. But a longer hash also takes longer to compute, to check, especially if a human has to check it, so it may not be worth having a longer hash for the tiny security improvement.


The first obvious answer is of course "The 512bit hash is better".

A more considerate answer would add to that: "... if the input is long enough". The reason is that while we wish the world and the hashes within that world are perfect, it is generally harder to generate a near-perfect, random-looking distribution in a bigger output given a small input. Thus, a longer hash might have undesirable properties compared to a shorter one if given too short input.

A more practical answer would ask: Are you birthday-bound? If not, forget about the issue, and just use the 128bit hash, which is faster and uses less storage.

If a birthday attack may be an issue for you (signatures?) you will most definitively not want to use a 128bit (or smaller) hash because 264 is a number that is quite feasible as an attack.

Other than that, unless some of the information involved is so immensely valuable that one or several of the largest nations in the world will dedicate the major part of their resources and their presumed super quantum computers for several years to brute force a single one of your hashes (how important are you!?), any non-broken hash is -- in practice -- as good as any other as far as the length goes.

It does not make a difference whether an attacker has to perform 2127 or 2511 or 210000000 steps.

2127 is by all means impractical, and unaffordable (for every realistic scenario), if possible.


One usage of hashes is data signature or checksum.

Assume I provide a file to downlaod for you, and once you downloaded the file you may need to make sure it's not touched(by man-in-middle, bad network, etc.), so here comes the solution.

I provide the checksum/hash of file for you(let say in SHA-512), now you check the checksum/hash of downloaded file and the both hash files must be the same now(but if you assume the hash data provided is no touched too).

You could be surprised that MD5 now is a deprecated hash algorithm. As security legends could hack it in a very awesome way, that you could have two completely different data with the exact one same size and exactly same md5 hash value.

So now I'm not afraid that maybe next year, 10 or 100 next year another legend could do the same thing with the SHAs family.

HMACs are the secure way of hashes. As you need to add more secret data to make the hash. Back in the file download example in above, now you need to make a HMAC-SHA-512 for checking data integrity with some secret value which only you and I know.(the secret val known as salt too).

More security? cannot trust noone in the world? HMAC doesn't work
So the last approach is the your own customized hash algorithm. Yes make it yourself. But obviously you need to do it very well.


A larger bit hash can provide more security because there are more possible combinations. Remember that one of the important functions of a cryptographic hashing algorithm is that it produces unique hashes. Again, if two different values or files can produce the same hash, you create what we call a collision.

So, in short, I can say that the longer the hash length, the more secure your information/system is!

  • 1
    so in theory, according to your answer ... if my hash algorithm is to xor then input against all zeros ... it would potentially have a very long bit lenght and thus be super <.< duper >.> secure >.< Commented Apr 7, 2022 at 14:32
  • 2
    I'm not sure what this answer provides that is different from any of the other answers.
    – schroeder
    Commented Apr 7, 2022 at 15:20

You must log in to answer this question.

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