Crypto-API Final Release Candidate

[Thomas DuBuisson]

To all who have provided feedback on crypto-api: (all BCCed - if you
aren't on l at h.o ML you won't see the follow-up discussion).

I intend to release crypto-api on Hackage Tuesday (Sept07).  The
proposed final version is on the darcs repo now [1].  I'm very
appreciative for all the discussion and design ideas, you can see that
many of the ideas have been used.  This is the last opportunity for
discussion before I upload (targeting 7 Sept).  Hopefully I've given
enough discussion time without being overly verbose (figured erring on
the side of verbosity is best).

Recent Changes:
* Moved modules to Crypto.* from Data.Crypto.* (ML and IRC comments)
* New 'getIVIO' function to get an IV using "getEntropy" then wrapping
with the IV constructor.
* Regarding the new Crypto.Random Module:
    * renamed 'generateKeypair' to 'buidKeyPair' for name consistency.
    * genBytesAI --> genBytesWithEntropy   (based on a blog comment)
    * RandomGenerator --> CryptoRandomGen (based on Duncan's comment on reddit)
    * SplitableGenerator --> SplittableGen and now "split" can't fail
(IRC comment)
    * newGenIO can't fail (for non-broken generators - broken
generators might infinite loop)

Likely future changes (please send comments!):
* Fix Crypto.Random once a Windows user sends a patch.  I never tested
it and don't believe I got it right by chance.  No (or 'few') Windows
users seem to be involved in l at h.o discussion / steering.
* Once a proposal to rework 'random' and move the CryptoRandomGen
class into the 'random' package is out+accepted, I'll remove the
related code from Crypto.Random.
* a signature class (see ML, supporting non-encrypting algs like DSA):
    class (Binary k, Serialize k) => Signing k where
        sign :: k -> L.ByteString -> B.ByteString
        verify :: k -> L.ByteString -> B.ByteString -> Bool
        buildSigningKey :: (CryptoRandomGen g) => g -> Either GenError
((k,k), g)

Less likely changes:
* Expand the BlockCipher class to include mode functions like cbc,
ctr, etc (for a performance win).  Once I see how big the win is and
am convinced we can't optimize to get it without bloating the class
then I might add them to the class and provide default instances
pointing at Crypto.Modes implementations.

Not wanting to be a tyrant, here are some other thoughts people have
brought up for discussion (which you can assume I don't like for this
library, but some made me stop to think):
* Using a data type instead of class for AsymCipher  (see ML)
* Using MPTC and allowing CryptoRandomGen instances to control the
generated type (see reddit).  This might be proposed for the reworked
RandomGen class, but not likely for CryptoRandomGen.
* Have a data type allowing named algorithms (data HashName = MD5 |
SHA1 | SHA256 | ... | OtherHash String)  include a new class routine
(hashName :: dsgt -> HashName) (see ML 'cryptohash' thread)
* Unified class for stream ciphers and other streaming algorithms (ex:
compression)  (ML)
* use a semantics for BlockCipher and Hash that doesn't require
blockSized inputs (see my original crypto overhaul e-mail which
detailed 3 possible semantics)
* a 'strength' field for each hash and cipher (also mine, but decide
it would be more likely for absurd misuse than any type of correct
use)
* a "Key" class to which all Cipher class keys would belong.  Rejected
for "over typeclass-ification", no real benefit.

Other TODO:
* Crypto.Padding still needed
* Expand test suite to other hashes, more test of current hashes, more
algorithm specific tests (perhaps most notably, block ciphers).
Contributers feel free to make more Test.* modules, perhaps one for
each algorithm?
* Expand test suite to include more properties (an encrypt . decrypt =
id property of some sort?  A stream cipher property checking correct
operation for streams feed 1 byte at a time vs multi-byte?  etc).
* Improve benchmarks, use CryptoRandomGen class in benchmark.

Yes, some of these changes means the version number will be inflating
somewhat rapidly, but it will mostly be added functionality so most
packages won't have to change anything be remain compatible (advise
you selectively import: "import Crypto.Foo (...)").

Cheers,
Thomas



[1] code.haskell.org/~tommd/crypto