[Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

[CC'ing maintainer of MonadRandom]

On Sep 3, 2010, at 1:59 AM, Thomas DuBuisson 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.

Also, the type-class approach is extensible in that new operations  
(for example for signing) can be added via subclasses. Later extending  
the key type above requires nesting.

>> 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).

I think mtl is only used for the instances, not for the class itself.  
Maybe the maintainer of MonadRandom is inclined to split the package  
if this would raise the number of users of the class.

> If MR the more agreeable path
> then I'll do it, though this means I use the unholy "fail" function.

You don't want to use monads because the Monad class defines the 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.

An advantage of using a MonadRandom class would be that the CryptoAPI  
would be independent of RandomGen or your new alternative. One could  
define random monads based on either.

Sebastian

-- 
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)