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