On 05/25/2010 03:11 PM, Thomas DuBuisson wrote:
Future Crypto Library Principles I propose two "new" libraries be built and receive some higher level of community attention. One is "Crypto" which will define type classes and a limited set of common generic algorithms (ex: HMAC, cipher modes of operation). The other is "crypto-algs" which implements (and instantiates type classes for) as many common algorithms as we can reasonably group together with similar interfaces. I feel the breakdown is important - if the community-accepted interface is separated from any algorithms then maintainers of alternate implementations are more likely to accept the interface.
Why two libraries instead of n+1? Wouldn't it make sense to just have one library (what you call "Crypto") define the interface as one package, and then have a number of packages that implement that interface as a series of other modules? This has the advantage that: (1) You only need to download the packages (and dependencies of said) for those crypto routines you need. (2) It removes the need for a separate authority to approve inclusion of newer / faster / better crypto implementations. (Thus speeding up the process and lowering the barrier to entry.)
Enumerating principles I support: * Lazy ByteStrings should be used for all input data
Really? Why? I've actually been considering going back to both the SHA and RSA packages and redoing them using strict ByteStrings. Recent experience has suggested that strict ByteStrings are almost always what I want, and building a fast lazy ByteString interface over strict ByteString routines seems like a pretty trivial task. - Adam