>>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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe