Crypto-API is stabilizing
thomas.dubuisson at gmail.com
Thu Aug 26 11:01:56 EDT 2010
>>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
> 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.
More information about the Libraries