DRBG pre-announce and a discussion on RNG/Crypto infrastructure

[Adam Wick]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3608 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20100603/4086dcc8/smime.bin