# Why unhashing is not possible? - Page 2

•  Subject
• Author
• Posted on

## Re: Why unhashing is not possible?

Unruh wrote:

This is ridiculous. Consider an input of the length of the output 'n' with
maximum conditional entropy. If the output would contain significantly less
entropy, say m < n, then the average runtime for a bruteforce search would
be 2^m instead of 2^n, and you'd have an attack against the hash.

Short to say, cryptographic hashes are best at mixing in all available
information without throwing anything away. That is, every little input
influences the output with maximum significance.

If the input is longer than the output, a hash is always impossible to
invert for arbitrary inputs - that's the very purpose of a hash. No one
every talked about that it should also be hard for specific inputs.

It's part of the algorithm if you use it solely as a hash.

## Re: Why unhashing is not possible?

???? A cryptographic hash tries very hard to look like a random selection
of the 2^N possible outputs(for a N bit hash). That preserves no
information. Information is what distinguishes the input from other inputs,
and a cryptographic has tries its best not to distinguish the outputs from
any other outputs. It, it tries its best to destroy all information in the
input. The reason for the "each bit influences the output" is precisely to
make this as true as possible. You also want to make sure that different
inputs produce different outputs. Ie, each input is a statistically
independent random choice of output. If one of the bits did not influence
the output, then you would not have an independent random choice.
Of course the output is actually a deterministic function of the input, but
one wants that deterministic function to act as much like a random
selection as possible-- ie to preserve the "no information transfer" as
possible.

Yes, you are again repeating what others said.

Who was using it as a hash? Using a keyed encryption as a cryptographic hash is
silly
both because it preserves the length of the input, and because it is easily
invertible.

## Re: Why unhashing is not possible?

Unruh wrote:

Why don't you simply use a purely random function? This would really
preserve no information, and would be absolutely useless.

Which is nonsense as well, since the same input leads to the same output -
so obviously is does distinguish outputs.

Then the function f(X) = "0" would be much better.

Wrong again. The purpose is to make every little bit of information in the
input influence the output, thus preserving it as much as possible (and the
limit being the output size and the randomness demand).

> have an independent random choice.

That is, this bit of information is not discarded.

Nonsense. Now get yourself familiar with the term "conditional entropy".

I throught we were talking about hashes.

Until you stop behaving stupid and think a little bit how one can use a
symmetric cipher to produce a hash function which is invertible for all
inputs shorter than output (including the padding).

## Re: Why unhashing is not possible?

Thanks everyone...

Hash references/explanations that I read referred to hashing as being
unique however from what you folks are telling me, "unique" in this
sense means "extreme remote chance of a duplicate being found".

Cheers / Health / Wealth / Peace to you all!

## Re: Why unhashing is not possible?

Yes. It is mathematically clear that if the input is longer than the
output, then the output cannot be different for all inputs. It can be
different for all inputs you happen to ever  try.

## Re: Why unhashing is not possible?

[hashing]

Hash alphabetic ASCII characters into octets, preserving case.
52**4 < 256**3 so quartets of alphabetic ASCII characters fit into
triplets of octets. The input is longer than the output, and yet
the output is unique.

Your "mathematically clear" statement needs to be reinforced with
a stricter definition of "all inputs", and what it means for an
input to be "longer than the output".

## Re: Why unhashing is not possible?

http://en.wikipedia.org/wiki/Entropy

or just smash a tumbler and try to "uncreate" it again from sherds.

Oh, it can. It's just very expensive. If cost is real-world computing
time, it's often far too expensive.

That's the trick.

Yours,
VB.
--
The file name of an indirect node file is the string "iNode" immediately
followed by the link reference converted to decimal text, with no leading
zeroes. For example, an indirect node file with link reference 123 would
have the name "iNode123". - HFS Plus Volume Format, MacOS X

## Re: Why unhashing is not possible?

Randell_D wrote:

Take one of the simpler types of hashes, it will make a better example.
Say you have a database key you want to map to values

A common technique is to take the ASCII value of the first character...
this is an 8-bit hash.

for example let's add the word  'Pie' to our hash table, since P has ASCII
value 0x50, our hash function says  "Pie" = 0x50

HashTable[0x50] = { :Pie => "blah blah " }

The key  'Apple' hashes to 0x41, so

HashTable[0x40] = { :Apple => "blah blah" }

Then we have the key "Pineapple" which also hashes to 0x50.
So we add that to our database....

HashTable[0x50] = { :Pie => "blah blah",  :Pineapple => "blah blah" }

Note that  We cannot examine "0x50" and know what we were looking for.

Since the database key is 24 bits, 72 bits, or even of variable length,
and our hash function has a much smaller range of outputs.

The only way we have of constructing a function to 'reverse' the hash
is to have some knowledge of what possible values might have been hashed.

This hash is clearly not suitable for cryptographic use, because there
are so few bits, and it's trivial to find something that hashes to 0x50
other than our desired input.

--
-Jimmy