On 13-07-28 05:27 PM, Kevin Cantu wrote:
AFAIK new algorithms using MD4 (and probably MD5) would also be simply wrong, too.
They were designed as CHFs; they are now weak-or-broken but code that's interoperating with old cryptosystems do need them from time to time.
CRCs and Checksums aren't CHFs and shouldn't be put anywhere near them. I'd be somewhat cautious even calling them hash functions, but I guess it's a short enough name.
I suggest (humbly and willing to listen to counterarguments) that we have a trait std::crypto::Digest and a trait std::hash::Hash, with default implementations of each that we consider state of the art, in std; and then a bucket of "extra" named algorithms that satisfy the same trait in extra::crypto and extra::hash.
In general I _think_ I'd like important / widely-used traits to be specified in std, even if "most" implementations don't live in std. There's value to getting the interface widely standardized.
The same issue comes up with a lot of other interfaces: the container types (hashtables and balanced trees), random number generators, serialization schemes, compressors and such are all like this: there are 95 different known, named variants someone _might_ want to use for some particular interoperability or taste reason, but I suggest that the interface and a promise of at least 1 "reasonably good" implementation -- hidden behind &Trait or a non-specified typedef or something -- ought to be standardized.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
