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.dubuis...@gmail.com
> wrote:
> On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer
> <s...@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
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
