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

Adam Wick awick at galois.com
Thu Jun 3 15:00:15 EDT 2010

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

More information about the Libraries mailing list