22

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?

rpach17
  • 345
  • 2
  • 3
  • 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 07: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
  • 1
    1. Which specific hash function are you working with? The answer may depend on the choice of hash function. For some hashes, increasing the length doesn't increase security to any meaningful degree. 2. We can't tell you what is more useful without more detail than is currently available in the question. – D.W. Apr 18 '17 at 20:24
  • Depends what the hash should protect against. Longer hashes are harder for attackers, at the same time they reveal more about the Input. In a scenario where the data and hash is presented (checksum) the longer hash does not really provide more protection against malicious modification. – eckes Apr 20 '17 at 23:13

5 Answers5

47

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.

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • 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](https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html), 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
  • You guys are getting really nit-picking. I'm making the assumption that the OP is using a standard cryptographic hash function, rather than rolling their own. – Mike Ounsworth Apr 17 '17 at 23:04
  • Note that it lack the fact that some hashing algorithm are designed to be slower to compute, which make them harder to brute force even for the same entropy. And they're algorithm with salt, I'm thinking of course for BCrypt. However BCrypt fits for password, not for hash on files. – Walfrat Apr 18 '17 at 07:29
  • 1
    Are there some rules/guides/standards for the length? Say "for each year futureproof, add N bits" ? Nothing exact, just some bascis – Martijn Apr 18 '17 at 07:51
  • 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?](https://security.stackexchange.com/q/6141/2138) meet your needs? – user Apr 18 '17 at 10:59
  • 1
    Do compare [If we had a “perfectly efficient” computer and all the energy in the Milky-way available, what number could it count to?](https://physics.stackexchange.com/q/257323/14091) on [physics.se]. // cc @NickT – user Apr 18 '17 at 11:01
  • Just to state the obvious, SHA-2 starts with 256 bit there is no SHA-128 – eckes Apr 20 '17 at 23:14
  • 1
    @eckes actually it starts with 224, but I'll update, thanks. – Mike Ounsworth Apr 20 '17 at 23:21
  • @Martijn yes various standards bodies define minimum security strength for specific classifications and lifetime expectation. Those can be mapped to hashes (digs) as well (taking birthday paradox as worst case into account even when collision attacks are not relevant in all modes). However they are all more or less educated guesses and you use them because you don't get fired if they fail ,) Even when they publish the numbers with a big "Post Quantum breakthrough" Disclaimer they are mostly betting of breaking the math (not brute force advances) – eckes Apr 20 '17 at 23:36
6

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.

user2233709
  • 745
  • 6
  • 13
1

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.

Damon
  • 5,211
  • 1
  • 20
  • 26
0

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.

-5

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!

schroeder
  • 125,553
  • 55
  • 289
  • 326
Misheck Samukoma
  • 1
  • 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 >. – CaffeineAddiction Apr 07 '22 at 14:32
  • 2
    I'm not sure what this answer provides that is different from any of the other answers. – schroeder Apr 07 '22 at 15:20