Replies

If I understand what you are saying, in order to get every possible input that would result in any 20 byte hash, you would need 1e27 bytes.

The question is how many inputs would you need to store to generate all possible 20 byte hashes?

That is a far smaller number.

If I have a unique 20 byte hash, to get into the account I only need ONE of the 2x10⁶ or so possible combinations that generates that particular 20 byte hash, I don't need ALL of them.

If I understand what you are saying, in order to get every possible input that would result in any 20 byte hash, you would need 1e27 bytes.

That was just to store the hashes produced by going through all of the possible 13-character printable ASCII passwords (to cite one example — there are also all the 14-character passwords and all the 15-character passwords, etc. — better order more drives).

The number of distinct 20-byte hashes is 2**160, or approximately 1.46e48, a far higher number.

The number of 13-byte printable ASCII passwords is 95**13, or about 5e25. There are 2.85e22 times as many possible 20 byte hashes as there are 13-byte printable ASCII passwords.

This is not to say there are no collisions (more than one 13-byte password producing the same 20-byte hash), but it should be extremely unlikely.

Unless there is an undiscovered flaw in the SHA1 algorithm, which would reduce the password search space substantially. That's always possible.

But the larger point is, it doesn't make sense for the government to be going after passwords when they have inside access to the providers and the carriers.