[Haskell-cafe] Re: cryptohash and an incremental API

[Vincent Hanquez]

On Wed, Jul 14, 2010 at 11:43:45AM -0700, Thomas DuBuisson wrote:
> Vincent said:
> > couple of comments around the hashes interface:
> >
> > * updateCtx works on blockLength, instead of working on arbitrary size...
> 
> So for performance reasons you seem to prefer Semantics 1.2?
> 
> """
> 1.2 Multiple of blockSize bytes
> Implementations are encouraged to consume data (continue updating,
> encrypting, or decrypting) until there is less than blockSize bits
> available.
> """
> 
> Also, I'll amend 1.2 and say the hashUpdate/encrypt/decrypt functions
> should only consume n * blockSize bytes, tracking the remainder will
> be done at the higher level.  Also, the higher level default
> implementations should only pass n * blocksize inputs to these
> functions.
> 
> I can see how that's reasonable and am strongly considering using
> these semantics instead of 1.1.

I'm not sure which document you are refering to here.
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.
 
> > * Why is the digest of a specific type ? I like representing different
> > things with different types, but i'm not sure what do you gain with digests
> > though.
> 
> This I am less flexible on.  My thought on how people will use this
> library is centered around the instantiation of classes on the keys
> used or resulting digests.  Anyone wanting ByteString results can
> simply use Data.[Serialize,Binary].encode.
> 
> Here is a user getting a sha256 hash:
>   let h = hash contents :: SHA256
> 
> or the type could be implicit due to context (not shown):
>   let h = hash contents

That's fine; I wasn't objecting but just wondering about it.

> > * is strength really useful in the Hash class ? it might be accurate when the
> > thing get implemented, but i'm not sure what would happens over time, and flaws
> > are discovered. would people actually updates it ?
> 
> Will people actually update it?  I hope so but if they don't are we
> really worse off than not having any strength numbers?  People who
> [snip]
> I don't consider this a win - crypto-api now enumerating all hash
> algorithms wanting Hash instances.

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.
 
> > The blockCipher should exposes the chaining modes as overridable typeclass
> > functions, with default generic implementations that use encryptBlocks. For
> > example the haskell AES package has different C implementations for each
> > chaining modes (e.g. cbc, ebc), and i suspect that using a generic chaining
> > implementation would slow things down.
> [snip]
> 
> These I do object to.  The key does not change as the CBC algorithm
> progresses, but contextual information does.  My initial mode
> implementations have types like:
> 
>     cbc :: (BlockCipher k) => k -> IV k -> ByteString -> (ByteString, IV k)

sorry, i got confused. Your type definition is clearly what should be done here.
 
> In other words, initialization vectors are explicit and separate from the
> key.  The type parameter on IV allows us to build an IV of proper size,
> something like:
> 
>     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 ?

> My interface was just a quick hack with me understanding it would
> likely change -  I didn't know there was a Haskell RC4 binding or
> implementation and will happily follow your lead here.  Is this
> implementation on hackage?

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.

-- 
Vincent