cryptohash and an incremental API

[Thomas DuBuisson]

Sorry for the double Vincent, forgot to include libraries at h.o

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

I've considered something more like

   data HashName = Tiger | MD5 | SHA1 | SHA256 | ... | OtherHash String
   hashName :: HashName

Forcing a standardized name so tools such as DRBG won't have to guess
or try to normalize:
    (`elem` ["SHA2-256", "SHA-256", "SHA256" ]) . map toUpper .
filter (not . isSpace))

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

Its been I thought but one I'm not convinced of enough yet because we
either have a problem of name standardization or crypto-api
enumerating hashes.


[wrt IVs]
> That's still sounds quite odd. When initializing my IVs usually, this is not
> something randomly generated, but something known on both side.

So for an example IPSec with AES CBC we have a ByteString of IV ++ Ciphertext:

   decryptRFC3602 :: (BlockCipher k) => k -> B.ByteString -> Maybe
(B.ByteString)
   decryptRFC3602 ctInfo =
       let m = runGetState  get ctInfo 0
       in case m of
                Left err -> Nothing -- Serialize decode error getting IV
                Right (iv,ct) -> snd (unCbc k iv ct)

In IPSec the IV is randomly generated by the encryptor, so the 'getIV'
method might be of use (or just use "liftM decode $ readFile
"/dev/urandom").

If both sides know an IV they wish to start with void of any
randomness then the job is even simpler:

   encryptCBCknownIV :: (BlockCipher k) => k -> Bytestring -> ByteString
   encryptCBCknownIV k pt =
       let iv = decode $ Lazy.pack [0..]
       in snd (cbc k iv pt)

   decryptCBCknownIV k ct =
       let iv = decode $ Lazy.pack [0..]
       in snd (unCbc k iv ct)

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

crypto-api is giving the developer certainty that any "iv :: IV k" is
"blockSize `for` k" bits long - which is a nice guarantee.  The cost
is that people wanting non-random IVs need to place their IV in a
bytestring and decode it via cereal or binary - not a high cost.

Cheers,
Thomas