Crypto-API is stabilizing

[Thomas DuBuisson]

>>class (Binary p, Serialize p) => AsymCipher p where
>>    generateKeypair :: RandomGen g => g -> BitLength -> Maybe ((p,p),g)
>>    encryptAsym     :: p -> B.ByteString -> B.ByteString
>>    decryptAsym     :: p -> B.ByteString -> B.ByteString
>>    asymKeyLength       :: p -> BitLength
>
> Regarding AsymCipher:
> Some algorithms do not lend themselves to encryption/decryption or have
> special properties which differentiate their use in enc/dec an
> signing/verifying.
>
> I propose the following two additions for the class:
> signAsym     :: p -> B.ByteString -> B.ByteString
> verifyAsym     :: p -> B.ByteString -> Bool
>
> This way algorithms can leave parts undefined which do not apply to
> them or hide their different behaviour.

I am strongly against classes for which we already know instanes will
need a good deal of undefined routines.

> Another possibility would be a split of AsymCipher into AsymCipherEnc
> (which is just like the old AsymCipher) and AsymCipherSig for
> Signatures. Textbook-RSA is special, since it can implement both
> classes with a minimum of effort, but a clean separation would be nice
> (and there wouldn't be that many undefined functions).

Perhaps even zero undefined functions.  I like this suggestion, though
I'm not aware of any haskell implementations that will take advantage
of a "Signature" class yet.  Unless someone can point to something
like a DSA or ECDSA on hackage I'll probably release crypto-api 0.1
without this class (it would still likely appear in a later version
after further consideration).

> Another thing:
> A central interface to get the output of a PRNG would be nice,
> preferably not constrained to Int like RandomGen.

Designing a random interface that provides something as high a level
as monad random, is easy enough to make instances for (like RandomGen)
and is feature rich enough to allow reseeding, additional entropy
input, personalization, and failure is a non-trivial design task.
Having ran into the dilemma of how to provide a reasonable high-level
interface for DRBG, I agree with your statement but don't know how a
solution would look.

FYI, BOS had a similar suggestion (on the blog) of moving away from
RandomGen but I'm not clear on what I'd move toward.

Cheers,
Thomas