On Wednesday, 8 August 2012 at 14:14:29 UTC, Regan Heath wrote:
I don't think there is any reason to separate them. People
should know which digest algorithm they want, they're not going
to pick one at random and assume it's "super secure!"(tm). And
if they do, well tough, they deserve what they get.
In this case, I'm not suggesting keep them separate to not
confuse those who don't know better. They're simply disparate in
actual use.
What do you use a traditional hash function for? Usually to turn
a large multibyte stream into some finite size so that you can
use a lookup table or maybe to decrease wasted time in
comparisons.
What do you use a cryptographic hash function for? Almost always
it's to verify the integrity of some data (usually files) or
protect the original form from prying eyes (passwords ... though,
there are better approaches for that now).
You'd _never_ use a cryptographic hash function in place of a
traditional hash function and vice versa because they designed
for completely different purposes. At a cursory glance, they bare
only one similarity and that's the fact that they turn a big
chunk of data into a smaller form that has a fixed size.
On Wednesday, 8 August 2012 at 14:16:40 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
function to pass the isDigest predicate. But they have many
similarities, which explains they are all called hash
functions. There
is enough room in a package to put several related concepts!
Crytographic hash functions are also known as "one-way
compression functions." They also have similarities to file
compression algorithms. After all, both of them turn large files
into smaller data. However, the actual use of them is completely
different and you wouldn't use one in place of the other. I
wouldn't put the Burrows-Wheeler transform in the same package.
It's just my opinion of course, but I just feel it wouldn't be
right to intermingle normal hash functions and cryptographic hash
functions in the same package. If we had to make a compromise and
group them with something else, I'd really like to see
cryptographic hash functions put in the same place we'd put other
cryptography (such as AES) ... in a std.crypto package. But
std.digest is good if they can exist in their own package.
It also occurs to me that a lot of people are confounding
cryptographic hash functions and normal hash functions enough
that they think that a normal hash function has a "digest" ...
I'm 99% sure that's exclusive to the cryptographic hash functions
(at least, I've never heard of a normal hash function producing a
digest).
