# Losing entropy after re-hashing a hash

Suppose you have a string AAA that was hashed with SHA1 to produce 606ec6e9bd8a8ff2ad14e5fade3f264471e82251.

If I rehash 606ec6e9bd8a8ff2ad14e5fade3f264471e82251 10x times with the same SHA1 algorithm, would the entropy keep on decreasing?

If so, would it ever reach a dangerous level to a point where AAA could be recovered?

P.S: SHA1 was just an example. Ideally, I'd use BLAKE2b or a SHA3 candidate.

• This could be related: crypto.stackexchange.com/questions/12505/… – jimmytann Feb 6 at 14:17
• There's a clarity Issue with the question; the meaning of "reach a dangerous level to a point where AAA could be recovered" is unclear. AAA can be recovered from the first hash (try it e.g. here), as well as from the second one (try 5af9d0ea5f6406fb0edd0507f81c1d5cebe8ac9c on the same site). So what's the fear exactly? Independently: entropy is defined for the random process that generates a string. It's zero or undefined for a particular string. – fgrieu Feb 6 at 14:44
• Or maybe it is asked how much entropy there remains after a number of iterated hashes, starting from an unknown random starting point with a given entropy? That would be a dupe of this, and asked in a different form there. – fgrieu Feb 6 at 14:44
• Use Argon2id version 1.3 (the newest version at the time of writing) for passwords if you have the appropriate hardware. Make sure to use a binding to an optimized native build. Follow the "official" recommendations for parameter choice. Design your system so that a password is only ever hashed once with Argon2 per time the user enters it. Argon2's method of increasing cost is safe when it comes to "entropy" stuff. It's arbitrary output length feature is also safe, unlike similar features in PBKDF2 or ad hoc schemes. – Future Security Feb 8 at 19:20

Let's assume your actual input/output has entropy (which it doesn't for a given string or output hash value).

If I rehash 606ec6e9bd8a8ff2ad14e5fade3f264471e82251 10x times with the same SHA1 algorithm, would the entropy keep on decreasing?

Yes, but by ever so tiny amount. Hashes are designed so that every bit is dependent on all the bits of the input. Hashes do get into so called cycles after iterating quite a few times, showing that entropy can and does decrease. It is however unlikely to influence practical situations.

The initial hash will of course extract the entropy into a maximum of slightly less than 160 bits.

If so, would it ever reach a dangerous level to a point where AAA could be recovered?

That's of course nonsense statement; the amount of entropy doesn't influence the one-way-function property of a cryptographic hash function at all.

Let's take an extreme and assume that, after a while, all many messages will generate the same hash (a next to impossible situation in itself). Then the (Shannon) entropy will be lowered. So in this situation it becomes more likely to generate this iterated hash by trying out different messages.

However, if you try and revert it you will find many messages instead of one, and it is impossible to detect which one is the original input message. So if anything, you've just made the function harder to reverse.

As example: I've "hashed" all bits of a fully random message into a single bit by XOR-ing them together. Entropy is hugely decreased to a single bit worth of it. Which message did I use to create this one bit of entropy, even if you (get to) know it is 0 or 1?

The entropy is not going to change in general. Here is the output of a python script that makes the 10 sha1 hash and compute the entropy

('606ec6e9bd8a8ff2ad14e5fade3f264471e82251', 3.787326145256008)
('872e371675df9bf6d8d510a768bd8c111107d4e7', 3.6873261452560073)
('e58e33b305a4d5637d1bcbf786875596d7f62fe0', 3.787326145256008)
('725732757ca3402ac5c62001bf377471e7c9580d', 3.6530559073332753)
('d74c173a570b676792e7f569ffc3bf8068bd9c30', 3.7898227820087547)
('93fce9149cee02f918ff1211bfbd196566147acb', 3.6746702095890935)
('27e3fc35e4c17c7a4f1c687d995a034ec368d95c', 3.758694969562841)
('8085ea82b4d2898cfb92431d64a6c60c3a2673d8', 3.7898227820087547)
('160f9cd062a925d068304d37b4b85108762b34a1', 3.7995817701478343)
('61352724fe0931447d6a0b6ebb4f0843b84aab5f', 3.7495817701478344)


Bear in mind that I copy the entropy function from other post and may vary on the implementation.

• Theoretical entropy of 606ec6e9bd8a8ff2ad14e5fade3f264471e82251 may be 3.78, however actual entropy is lower due to the fact that a lower entropy string is the input. – Woodstock Feb 6 at 15:29
• Entropy cannot be increased by hashing. If the entropy goes up then something is terribly wrong with the calculations. I think you're confusing distribution - as calculated by some unspecified algorithm / implementation - with entropy. Please include the algorithm / implementation used with your answer. – Maarten Bodewes Feb 6 at 19:48
• Entropy of a value is not well-defined! – fgrieu Feb 7 at 15:05
• @fgrieu Directed to poster, but notifying fgrieu too for courtesy. To elaborate, entropy is a property of a random variable. Not of a value. (Legitimate definitions of entropy are all based on a probability mass function. No PMF means no entropy. Not even zero entropy.) Asking what the entropy of a string "ABC" is is like asking what the mean, minimum, maximum, mode, or variance of the number 5 is. – Future Security Feb 8 at 17:55
• Sometimes people refer to values having entropy, ie. "a high entropy key". But that's improper, unless you recognize it as shorthand for "a key sampled from a high entropy distribution". – Future Security Feb 8 at 17:59