Re^3: OT: Cracking hashes made easier

If you're using a 128 bit hash, and your key+password is less than 16 characters, then the shortest reverse lookup is probably the right one.

If we include the fact that key+password are usually made up of typeable characters, then the shortest reverse lookup that is typeable is probably the right one out to 19 or 20 characters.

I suspect that fairly few people use a long enough secret key to provide protection against this fact. But if you do, then you're right that the secret is still protected.

Comment on Re^3: OT: Cracking hashes made easier

Replies are listed 'Best First'.
Re^4: OT: Cracking hashes made easier by thor (Priest) on Nov 11, 2005 at 20:02 UTC
If you're using a 128 bit hash, and your key+password is less than 16 characters, then the shortest reverse lookup is probably the right one. Because I'm curious and because I know that you're capable (-: willing is another question :-), would you mind explaining the math here? thor `Feel the white light, the light within Be your own disciple, fan the sparks of will For all of us waiting, your kingdom will come`	[reply]
Re^5: OT: Cracking hashes made easier by tilly (Archbishop) on Nov 11, 2005 at 22:05 UTC
15 characters at 8 bits per character is 120 bits. So the hash maps 2120 15 bit strings into a set of 2128 hashes. Plus 2112 14 bit strings. And so on. Assuming that the hashing algorithm does a good job of making it look like a given string goes to a random hash, the probability of a given string having a collision is about 1/28=1/256. (Let's ignore the relatively small adjustments from smaller strings and collisions.) If there isn't a collision, then only one reverse lookup is under 16 characters, and it is yours. That means that the odds that you are the shortest reverse lookup are about 99.5%, which qualifies as "probably" in my books. At 16 characters the math gets much more complicated. The problem here is that the strings could map to all of the hash values if they spread out perfectly, but they clump. There are hash values that have multiple strings hashing onto them, and those clumps mean that elsewhere there are hash values that are not mapped onto. The distribution of how many strings hash to a single value is given by the Poisson Distribution with a rate around 1.005. So about 36.6% of the hash values only have one string map onto them, which means that a similar percentage of strings can theoretically be recovered from the hash value. At 17 character strings the number of strings so overwhelms the number of hash values that there are always collisions, usually hundreds of them. The typeable calculation is similar, except that you lose a bit over a bit per character because most characters are not typeable. I was too lazy the first time around to work out how much over a bit per character you lose.	[reply]