New hash API: namespace

[Jonathan M Davis]

On Monday, June 25, 2012 12:24:44 Piotr Szturmaj wrote:
> Jonathan M Davis wrote:
> > On Monday, June 25, 2012 11:35:33 Johannes Pfau wrote:
> >> OK, so I understand std.util is probably not a good idea.
> >> 
> >> So the candidates for the namespace are:
> >> * std.crypto.hash
> >> * std.checksum
> >> * std.crypto.hash and std.checksum
> >> * std.hash
> >> 
> >> and the same with hash replaced by digest.
> >> So which one should we use?
> > 
> > The previous discussions on this resulted in us going with std.hash.md5,
> > std.hash.sha1, and std.hash.crc32. I don't see any reason to change that,
> > and crypto was specifically _not_ chosen, because crc32 isn't
> > cryptographically sound. But std.hash encompasses things quite nicely,
> > since they're all hashes.
> IMHO crypto should be chosen because beside of hashes there are other
> cryptographic primitives (ciphers, PKI, MACs, etc.) and it would be nice
> to have them in one place. std.hash is too narrow because when std gets
> crypto there will be too many namespaces like std.ciphers, std.ssl,
> std.mac. All of them will nicely fit in std.crypto or similar.
> 
> As you can see crypto isn't good candidate for checksums so another
> package std.checksum is proposed. Likewise mixing checksums and
> cryptographic hashes under one namespace (std.hash) isn't a right choice
> IMO.
> 
> Having cryptographic primitives splitted to std.hash and std.crypto.*
> isn't a good choice either.

Except that the same hashes could be used for either checksums or crypto stuff. 
It makes no sense to sense to split them between two packages. And you could 
probably get into arguments over whether any particular hash was 
cryptographically sound, particularly since that can change over time, can't 
it, given that at least part of what determines whether a hash is considered 
cryptographically sound is how easy it is to break. SHA-1 may or may not be 
considered cryptographically sound now, but it sure won't be forever, so 
putting it in std.crypto would become decreasingly accurate over time.

So, as far as the hashes go, it makes the most sense IMHO to just stuff them 
all in std.hash and be done with it. If we ever end up adding crypto-specific 
stuff to Phobos, then that stuff can go in std.crypto, but the hashes are _not_ 
crypto-specific. They just so happen to be used in cryptography. They aren't 
restricted to it.

- Jonathan M Davis