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