Announcement of work in progress: Shaskell sha2 library

[Dominic Steinitz]

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 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,
>
> Peter