Re: cryptohash and an incremental API
On Thu, Jul 15, 2010 at 2:24 PM, Vincent Hanquez
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
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
participants (2)
-
Thomas DuBuisson -
Vincent Hanquez