Sorry for the double Vincent, forgot to include libraries@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