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 Apr 17 '17 at 23:41
  • 1
    For what kind of purpose ? Passwords, files, others ? – Walfrat Apr 18 '17 at 7:29
  • 7
    Infinite hash length provides infinite security (and zero usefulness). – Dmitry Grigoryev Apr 18 '17 at 10:37
  • 3
    zero length hashes provides no security and zero usefulness :) – Viktor Mellgren Apr 18 '17 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 Apr 18 '17 at 18:22

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.

| improve this answer | |
  • 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 Apr 17 '17 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 Apr 17 '17 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? – user253751 Apr 17 '17 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 Apr 18 '17 at 10:36
  • 3
    @Martijn Does Amount of simple operations that is safely out of reach for all humanity? meet your needs? – user Apr 18 '17 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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |

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.