I understand that it is important to use well known and well tested hashing algorithms instead of designing my own. For such there often are reference implementations available, which initialize the needed constants with manually picked random numbers.

When I use such implementations, does it improve security to pick custom constants? I would expect an attacker to use the most likely values when bruteforcing my hashes, which are those from the reference.

A strong cryptographic hashing algorithm shouldn't be breakable, not even with rainbow tables when using salting. So from a theoretic point, there shouldn't be much of a difference. However, I'm not an expert so I'd like to hear what you say.

  • 4
    If changing those constants improved security, the designers wouldn't have made them constant. Aug 19, 2014 at 6:45
  • 2
    Does asking this question mean you're implementing the functions yourself? On top of not designing your own algorithms you should use a well-known library for the implementation as well.
    – Fsmv
    Aug 19, 2014 at 19:28

4 Answers 4


No. The constants are part of what make the hash secure, and the constants in the specifications are what have been used in the cryptographic community's examinations of the hash functions that we currently believe are safe. It has been shown that intentionally badly chosen constants can break a hash function in subtle but exploitable ways, and coming up with your own constants could inadvertently leave you with a weak hash function as well.

  • Inversely they could strengthen your hash as well if you select correctly.
    – user42209
    Aug 19, 2014 at 3:26
  • 22
    @caseyr547 And dousing yourself with gasoline each day might protect you from alien attack, but without independent verification that this is indeed the case, it can only be classified as a stupid thing to do. You're introducing substantial risk for a minimal chance of a reward that you won't ever be able to demonstrate you've actually gotten.
    – Xander
    Aug 19, 2014 at 3:32
  • 1
    if you want to douse yourself in gasoline under the whitehouse in the safest place on earth or on the doomsday plane i don't think its going to hurt anything.
    – user42209
    Aug 19, 2014 at 3:43
  • 7
    The S-boxes of DES are another example, where NSA supplied constants that at the time appeared to make no difference in terms of security but later were shown to strengthen the algorithm against some attacks. Aug 19, 2014 at 7:12
  • So as an example: weblogs.asp.net/jongalloway//… uses as entropy "Salt Is Not A Password". So what you're saying is that I should not replace that with a custom string?
    – Nzall
    Aug 19, 2014 at 8:40

No, due to reasons you have already stated: Don't design your own algorithms. You can achieve resistance from rainbow tables by using unique salts, no need to mess with the constants of your hashing algorithm. The algorithms have been subject to thorough cryptoanalysis by international experts, like for NIST SP800-90 Dual Ec Prng, its likely you won't have the resources to do the same for your constants. However, in most cases the numbers are chosen very randomly. You might even have advantages from chosing your own constants, in some cases, but I still don't recommend it.

Edit: fsmv has pointed out that you shouldn't implement the hashes yourself, but use a library. I agree. If you really wanted to use your own constants, get a well-known library implementation (watch out for the license) of the algorithm, and apply your changes to that code. The implementations have been made sidechannel attack resistant.


I'm not a security expert, but didn't the NSA get a bad reputation for intentionally choosing breakable constants for one of the NIST standards a while ago?

It depends on your threat model I guess. If you're worried about the NSA, then maybe you should hire the best cryptographers in the world and have them find better constants. Otherwise, just go with what's in the standards, because chances are they're pretty darn secure against other agents.


Short answer: No

The constants are part of the algorithm. If you don't trust the constants, then don't trust the algorithm. It is worth looking at some examples.

Merkle-Damgård hashes

One constant that could be changed in such an algorithm is the IV. For security analysis, changing the IV is equivalent to prepending the data with one block of key material. But the prepending would be preferred due to not needing to change the actual algorithm.

However it is already known, that just prepending some key material is not a good way to construct a keyed hash. A better approach would be to use a HMAC construction.

The IV is not the only constant in a Merkle-Damgård hash. There are constants in the compression function as well. If you choose your own constants, there is significant risk, that they would be weak for some reason. So even if all research point at the original being secure, your version might be weak. Should a weakness be found in the original algorithm, it is unlikely you managed to come up with better constants.

In fact in order to come up with better constants in that case, you'd basically have had to find the weakness and a solution. In other words if you could not write a paper about why your constants are better than the originals and get it accepted in a journal about cryptography, then your constants aren't any better.


This is a good example of not trusting the constants. The original constants came with no explanation of how they were constructed. That is a warning sign, and those constants shouldn't be trusted.

Further analysis of how those constants could have been constructed revealed a possible backdoor. The entire algorithm is now considered suspect.

If you wanted to use that algorithm, you shouldn't be using the original untrusted constants. But if you generated your own constants, how could you make anybody else trust your constants?

In fact with the knowledge we have now, DECDRBG with nonstandard constants is one of the simplest way to create a cryptographic algorithm with your own backdoor and make it look like an innocent mistake.

DECDRBG shows why once there is justified skepticism about the constants in an algorithm, you shouldn't trust the algorithm until somebody come up with a real criteria to decide what is good constants for the algorithm.

You must log in to answer this question.

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