Announcement of work in progress: Shaskell sha2 library

[David Mercer]

On 11/21/05, Dominic Steinitz <dominic.steinitz at blueyonder.co.uk> wrote:
> 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.

Oh that is excellent! I'll go look that up and make sure my toplevel
interfaces conform to that.  Right now they follow that in Peter
Simons' Digest.hs; it that is different I'll change to your standard,
as I haven't finished the padding code that interfaces to the outside
world yet either, so it's no skin off of my nose!

> 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.

This project was begun (last week!) as an alternative to my updating
the openssl wrappers that I found that already supported sha1, and
needed to be extended to use the sha2 family of message digests, which
of course have been in openssl for a long while (I'm acquainted with
Ben Laurie from a number of mailing lists and online fora for years
running now).

I have found the C and C++ implementations of the FIPS 180-2 spec to
be, while certainly fast, very hard to read and correlate with that
spec.  Wrappers in other languages, which is how almost all obtain
their crypto functions, are little better.  None of them can ever
(feasibly) have any runtime or termination properties formally proved.
 Finding this state of affairs deeply unsatisfying on aesthetic
grounds (which I have for years, just not specifically in regard to
Haskell), I began the instant project.

> 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 am intending to do all of the stateful bits are both pure and
monadic versions.  The monadic version with an unboxed mutable array
for the inner loop's hash state will hopefully be tunable under ghc 6
to run within a binary order of magnitude of the performance of C++
implementations of the spec.

> 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.

Unfortunately they do, they just relaxed it to a notification
requirement.  Which means I had to email the NSA and Commerce Dept. at
a predefined email address before posting to the web, and have to put
a disclaimer somewhere stating basically that persons from 'naughty'
places can't download, persons from the 'good' places can, and bugger
all if I know for folks in the middle.  The paranoid will of course
(rightly?) presume that the NSA now just merely want to packet sniff
somewhere and watch who downloads from crypto sites, and see who might
be naughty.  But you're in the uk, which is good! :-)  Long and short
of it is that I personally just can't directly email a source file to
a 'bad person'.  This all of course is the rules for open source,
closed source is still stricter.  See the documents referenced in my
disclaimer if you want to hurt your brain with Federal legalese:
http://davidmercer.cust.nearlyfreespeech.net/projects/shaskell/export.txt

Those are the pertinent sections when you read everything recursively
referenced starting from the Export section on page ii of FIPS 180-2,
which is where SHA2 is
defined (spec is public domain and non-export controlled, my local
mirror is at):
http://davidmercer.cust.nearlyfreespeech.net/projects/shaskell/fips180-2withchangenotice.pdf
And I did indeed send the requisite email to Big Brother last night
before seting the
read bit on my posted files.

The bits in the email exchange you quote below are indeed pertinent to
a number of issues I've been grappling with this past week, as the
folks on #haskell can attest! I'll have to do more reading on them and
any follow ups that might be in the archive, thanks indeed for that
reference!

I just want to emphasize again how awesome I've come to see Haskell as
during this project.  Nearly all of the formulas and definitions in
the specification for sha2 translate one to one into pure, stateless,
lazy haskell.  And are pretty much just a rendering of those typeset
formulas into a representation with ascii identifiers instead of
sigmas and such. My goal for the stateful version is to as closely as
possible follow the pseudocode for the inner loops in the spec as
well.

And once we're done, then we start attacking it with Agda to see what
is provable about it!  However much that ends up being, it'll be more
than one can prove about anything on the FIPS 180-2 validated
implementations list.

Cheers,

David Mercer
Univ. of Arizona
Tucson, AZ


> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>