cryptohash and an incremental API

[Vincent Hanquez]

On Thu, Jul 15, 2010 at 06:13:05PM -0700, Thomas DuBuisson wrote:
> > While thinking about it, i'm not sure if tracking the remainder should be left
> > at the higher level; The change will trickle through the finalize function,
> > which might not be very pratical.
> 
> I'm not a fan of changing the API because some particular C bindings
> would be inconvenienced.  I can sympathize but it doesn't seem like a
> strong enough argument when the argument on the other side is that we
> are removing duplicate code from all hash implementations.  Anyone
> else reading? Could other people weigh in on this issue too?

Actually, I realised a bit after posting that I'm talking crazy.
I don't mind actually where the buffer is handled, since it doesn't have
any relation on the underlaying implementation. i.e. the implementation
could still be happy to process smaller things than blockSize, and still
be able to fit the Hash interface.

> I'm considering this, how its loss would impact DRBG, and how many (if
> any) other libraries can make any reasonable use of "strength" without
> being overly dumb about its use.  Still tempted to keep it, bad users
> of hashes can always be bad without our help anyway.

Just a quick stab in the dark, what about in the class a "hashName :: String" ?
it would be easy to have in DRBG a function that match name to strength:

Something like:

getStrength :: Hash a => a -> Int

Regardless of either strength is implemented this way or not, would that be a
good idea to have a name field for ciphers and hashes ?

> Right, this was my turn to be dumb. I just now implemented it as:
> 
>     getIV :: RandomGen g => g -> (IV k, g)
> 
> So yes, I'm pulling bits from an RNG to construct an IV but we should
> avoid the dependency on MonadRandom.  If someone doesn't like
> RandomGen then they can always build a random bytestring of sufficient
> length (using whatever method) and run Data.Serialize.decode.

That's still sounds quite odd. When initializing my IVs usually, this is not
something randomly generated, but something known on both side. Semantically as
well, i'm not sure you could describe an IV as being random, since it has been
known by both side of a block cipher. (i.e. only one side would generate random
bytes in usual cases)

To me an IV should just be a function of a input byteString, and that let the
application of the interface pull the IV bytes from any place it need to.

-- 
Vincent