New hash API: namespace

[Felix Hufnagel]

+1 for
hashes into std.hash
and cryptographic primitives into std.crypto

and we should have a std.net (std.uri, std.socket, std.socketstream ,  
std.net.curl, ...),
std.io. for (Outbuffer, file, ....)
and probably std.database or something like that for (csv, json, xml, ...)

...


Am 25.06.2012, 17:31 Uhr, schrieb Jonathan M Davis <jmdavisProg at gmx.com>:

> 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


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/