# Why are the initial states of hashes functions (like SHA-1) often non-zero?

There is already a question asking "Why initialize SHA1 with specific buffer?" and my question follows on from this:

Why are the initial states of hash functions often non-zero?

For most, I have been able to find a clear explanation of where the initial values come from, and they are frequently nothing-up-my-sleeve values. That is, they are chosen precisely because they have no significant structure. However, if that is the case, why can they not be left at zero? Is it simply that a zero initial state is itself too suspicious?

(Other related question: "Initialising Sha-512")

-

In early years of hash function design it was unclear how to choose constants (not only initial vectors), and it was widely assumed that the more random they look, the more secure the function is. There is still not much research in this direction. However, there have been several attacks (rotational cryptanalysis, slide attacks, internal difference attacks) that exploited similarity between the constants and their low Hamming weight. It may happen that some choice of constants yields a weakness or even a backdoor that allows a faster collision/preimage search.

Recent attacks on Keccak/SHA-3 would have been slower if Keccak state were initialized with some weird constant, not zero as it is now. This is a property of the Keccak permutation, whereas the encompassing sponge construction is invulnerable to the initial vector choice.

Another reason is to choose distinct IVs to differ functions that are identical, but truncate the output to a different number of bits (like SHA-224 and SHA-256).

-
In general, all zero/one constants is kind of risky, but most things - even with very obvious patterns - are ok. See Salsa20's "expand 32-byte k" for example. –  nightcracker Oct 28 at 15:37
"some wierd constant" - And this is where i get a little confused. Given the choices are explicitly not very wierd (just that they're not quite as obvious as 0x00.. or 0xff..) it seems like one should be able to modify the first inputs of an attack to achieve the same outcome, given the IV is known? –  figlesquidge Oct 28 at 16:03
@user8911: Typically, the kinds of things you may want to avoid are e.g. having the IV be equivalent to itself rotated by some number of bits, or perhaps reversed and/or inverted, or otherwise having some simple bit pattern that might make an attacker's work easier. A random IV is very unlikely to have such a pattern, but may raise suspicions if you can't explain why it was chosen; hence "nothing up my sleeve" numbers, which are supposed to be free of such patterns while still not having enough degrees of freedom to hide a back door. –  Ilmari Karonen Oct 28 at 18:13
The combination of your comment Iimari and Dmitry's answer provide a very clear answer to my question. Dmitry: Assuming you agree with the explanation, I would feel something like Ilmari's comment would improve your answer. nb: clear $\neq$ correct, so I won't be accepting this just yet in case someone points out an issue I didn't know of! (After all, if i knew what the right answer was I wouldn't have to ask. thus I am clearly not able to say whether your answer is correct or not!) –  figlesquidge Oct 28 at 18:18
There is subtlety: the reduced version of Keccak would be stronger, it is true, but for the full version this has no effect (at least this is the impression). Moreover, having nontrivial IV in addition to round constants makes the whole structure more complicated and less transparent. It becomes more difficult to argue the resistance to certain attacks, because you would have to prove that your countermeasures do not interact badly with each other. Hence my strategy would be to have fewer but more secure components. –  Dmitry Khovratovich Oct 29 at 12:30