Crypto-API is stabilizing
Marcel Fourné
marcel at bitrot.dyndns.org
Tue Aug 24 07:18:58 EDT 2010
Thomas DuBuisson wrote:
>[1]
>http://tommd.wordpress.com/2010/08/23/a-haskell-api-for-cryptographic-algorithms/
>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.
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).
Another thing:
A central interface to get the output of a PRNG would be nice,
preferably not constrained to Int like RandomGen.
MonadRandom has with getRandomR a nice function, since it takes an
interval (possibly using type Integer), which is very comfortable for
asymmetric cipher usage.
A central interface could spare AsymCipher-implementers the effort of
duplicated work - we are lazy after all. ;-)
Also: Sorry for entering this late into the discussion!
Have a nice day,
Marcel
--
Marcel Fourné
OpenPGP-Key-ID: 0x74545C72
A good library is preferable to a tool, except when you just need that
one tool.
More information about the Libraries
mailing list