cryptohash and an incremental API

[Thomas DuBuisson]

On Thu, Jul 15, 2010 at 2:24 PM, Vincent Hanquez <tab at snarc.org> wrote:

[Re: Semantics of Hash "updateCtx" and my desire for semantics option
1.2 (replacing my original preference for semantics 1.1)
>
> I'm not sure which document you are refering to here.

http://www.haskell.org/pipermail/libraries/2010-June/013782.html


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


[Re: 'strength' field of the Hash class]
> indeed, just that strenght looks like a warm-fuzzy-feeling value, that might be
> wrongly used to choose a hash algorithm automatically or something. Otherwise i
> really don't mind.

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.

>>     buildIV :: (BlockCipher k, MonadRandom m) => m (IV k)
>
> I'm not sure i understand this however.  In particular the MonadRandom bits,
> why is it there ? Is this pulling bits from a random generator to construct an
> iv ?

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.


[re: the RC4 implementation and StreamCipher class]
> No, it's not hackage yet, I'll clean it up and put somewhere accessible in the
> next couple of days.  I'm not sure I can be considered a stream cipher expert
> yet though.  I'll try to gather some different algorithms implementation to see
> how it can be generalized to.

Sounds good.

Cheers,
Thomas