David, The Haskell Cryptographic Library consists of contributions from different authors which I have wrapped to give a uniform API, written a test suite and darcsized and cabalized. But caveat emptor! I am happy to incorporate new contributions. A different approach would be to provide an interface to openssl and Peter Simons has already done something along these lines, see http://cryp.to/hopenssl/. The latest version of openssl supports SHA-256 for example. From an industrial strength point of view, this is probably the way to go. Peter had a view that all "crypto" algorithms (I include hashes here) should have monadic versions- see below - even though they are all pure. Neither he nor I got round to doing anything about this. I'm not a lawyer but do hash functions count as encryption? There are no keys and you can't recover the data. And haven't the regulations been relaxed recently? Lots of publicly available packages offer SHA-256. Dominic. On Monday 07 Feb 2005 8:27 pm, you wrote:
Dominic Steinitz writes:
I'd suggest not touching anything to do with ASN.1 as I have now got a prototype of the re-write which will parse an X.509 certificate and extract the public key.
Sounds great. I'll update the repository every now and then so that I can see what's going on. I was wondering about OpenSSL ... Have you made FFI bindings to the library? Are you aware that I've made some for EVP digests too? Maybe we could throw together?
My main interest in Codec is in unifying the API; hiding the symmetric ciphers and digests behind one simple type class or monad or whatever it will be. I want to use those functions without knowing which one I am using.
I'm not sure how asymmetric ciphers fit into that; they're typically used differently, not for octet streams.
It seems that the latest ghc from CVS comes with several changes that break compilation of the code. I'll try to get that fixed without becoming incompatible with the 6.2.2 release in turn.
I'm surprised as I am running 6.2.2 [dom@tility dom]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.2
Well, GHC is at 6.5 by now, if you use the CVS version. ;-)
I think you need both the pure and monadic versions. They really are pure functions but sometimes you don't have all the data you want to encrypt available in one go.
A State monad is a pure function. If you have
aesM :: [Word8] -> State AES [Word] initAES :: AES
then you have
aes :: [Word8] -> [Word8] aes x = evalStateState (aesM x) initAES
just as well. But the reverse is impossible. I think _all_ ciphers and digests should be State monads. It means that an awfully lot of combinators can be written as monad transformers:
asciiArmor :: ([Word8] -> State st [Word8]) -> [Word8] -> State st [Word8]
Block chaining, encoding, layering of ciphers, permutations and all that can be written independently of what the actual cipher is. A cipher is just a transformer with state: we can run it with runState, we can compose it, and we can fool around with the input/output stream.
That's the way to go, IMHO. I've used this exact same design in Postmaster to build the ESMTP state machine, and the flexibility is staggering. I've come to love monads by now. ;-)
Anyway, that's all just speculation. We'll see whether I can whip up a nice module which shows what it would look like. Unfortunately, my time is very limited too. It's a shame, really.
Oh well, I you'll find some spare time and get your ASN.1 parser done. I'm looking forward to having SSL/TLS support in Postmaster soon then. ;-)
Take care,
Peter