Is there a reason this belongs under the Data. prefix? Why not break it out into Crypto, so future implementers of algorithms can also put their stuff under there. Everything at some level can be seen as Data, and it would be nice to start moving out of the overcrowded module hierarchy. 


On Fri, Sep 3, 2010 at 1:59 AM, Thomas DuBuisson <thomas.dubuisson@gmail.com> wrote:
On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer
<sebf@informatik.uni-kiel.de> wrote:
>>  data Key = Key {
>>               encrypt   :: B.ByteString -> B.ByteString,
>>               decrypt   :: B.ByteString -> B.ByteString,
>>               keyLength :: BitLength,
>>               serialize :: B.ByteString}
>>
>>  rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)

One reason against this is simply that all the other constructs
(block/stream cipher, hashes) are classes, it would be odd for there
to be a single exception.  A better reason is the data structure has
no way to implement generateKeyPair.

> Why not use
>
>    generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))

Because MonadRandom dictates mtl, and is heavier weight than a single
class.  I was hoping to keep this agnostic (mtl is only required for
testing or benchmarks in crypto-api).  If MR the more agreeable path
then I'll do it, though this means I use the unholy "fail" function.
Even if that's the case (and more people weighing in would help) I
still want to include Data.Crypto.Random and welcome comments.

Cheers,
Thomas
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe