The review of std.hash package

[Chris Cain]

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, 
travert at 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).