Re: Why unhashing is not possible?

In article <barmar-C819FC.17045927122007@xxxxxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

In article <k1hcj.12858$vd4.5964@pd7urf1no>,
roberson@xxxxxxxxxxxx (Walter Roberson) wrote:

In article <uvgcj.20007$wy2.19474@edtnps90>,
Unruh <unruh-spam@xxxxxxxxxxxxxx> wrote:
"Sebastian G." <seppi@xxxxxxxxx> writes:
Barry Margolin wrote:
How could the hash possibly be guaranteed to be unique?
For a limited set of inputs, this is very easy.
Yes. then it is not a hash. It may be an encryption, or a translation.

"Minimal perfect hashing"

But the types of hashes and their properties are very dependent on WHY
you're hashing. The algorithms you use to implement a symbol table
(which is where perfect hashing becomes useful) are completely different
from those used for cryptography (where it's important that it be
difficult to generate the same hash) or password encryption (where
irreversibility is critical).

Types of hashes and their properties exist apart from why
you are hashing. Why you are hashing governs your choice of which
type of hash (and thus which properties) you would rationally
select. Your choice of whether to use an axe or a shovel to dig
a hole in the ground does not change the properties of axes and
shovels, but sometimes the axe would be the better choice (e.g.,
ice axes in ice, or digging axes when dealing with a forest fire);
sometimes a shovel would be better.

The point is not relevant to Bill Unruh's statement that a "hash"
which is unique is "not a hash", which is what this subthread is about.
Your paragraph, quoted above, implicity agrees that "perfect hashing"
is a type of hashing; as perfect hashing hashes to a unique result
(over input it was designed for), Bill's statement appears to
be incorrect in context (which the original poster did not restrict
to cryptographic hashes.)

Sebastian's definition of what a "hash" is appears to me to be valid.
It's just that most things which are technically hashes are not
very useful for specific purposes (just like most things that
are "compression" functions aren't very useful for much.)
.

Relevant Pages

  • Re: "index" efficiency... any help or ideas?
    ... no general purpose hashing method, no matter how good, is good enough ... to prevent the possibility that everything hash into the same place. ... > Downside of hashes; if the data is stored externally, ... > perfect hashing are techniques that require analysis of the data in advance, ...
    (alt.lang.asm)
  • Re: "index" efficiency... any help or ideas?
    ... > dealing with different searching algorithms. ... > cons of hashing vs. binary searching. ... That's the killer reason for using hashes in this application. ... Searching a hash table is ...
    (alt.lang.asm)
  • Re: disabling password request when connecting from the LAN
    ... > Seems the hashing is actually applied to each 7-byte half ... That's true only for LM "hashes" (I put that in quotes because it really ... the way the cracking programs divide the hash in two. ... >> Steve Riley ...
    (microsoft.public.win2000.networking)
  • Re: Expanding hash function bit width
    ... >I have an idea to expand the bit width of any hash function H. ... start the hashes by hashing different input ...
    (sci.crypt)
  • Re: Hashing
    ... using elfhash() for the hash function, and a closed hash table 30,241 in ... tokens, but for a first alpha version system is acceptable. ... However, I've isolated the whole hashing functionality, so that swapping it ... (just a little slow when getting above 20,000+ labels). ...
    (alt.lang.asm)