Announcement of work in progress: Shaskell sha2 library
dominic.steinitz at blueyonder.co.uk
Mon Nov 21 16:11:45 EST 2005
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
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
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.
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 at 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,
More information about the Libraries