To all who have provided feedback on crypto-api: (all BCCed - if you aren't on l@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@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