[Cryptography] CFB/OFB/CTR mode with HMAC for key stream

Markus Ottela oottela at cs.helsinki.fi
Sat May 6 09:47:09 EDT 2017

On 02.05.2017 01:55, Jon Callas wrote:

>> On May 1, 2017, at 12:07 AM, Memory Vandal <memvandal at gmail.com> wrote:
>> Hello List,
>> I was wondering if using HMAC with something like SHA-256 to create a key stream in CFB/OFB/CTR mode is a bad idea.
>> Considering that in CFB/OFB/CTR modes, the cipher required in the mode is used only to perform encryption operation for both encryption and decryption, a HMAC can be used to generate a key stream.
>> So, the overall CFB/OFB/CTR mode remains exactly same with exception of using HMAC in place for a cipher. The key being used as HMAC key while IV can be as the HMAC message.
>> I am not a cryptographer but, have some experience with implementing cryptography. I could not come up with reasons as to why this could be a bad idea.
> I believe that you're describing using an iterated hash function (HMAC is a keyed wrapper function) to create a key stream and then use that as a stream cipher.
> Yeah, this has been called MDC for something as obvious as "Message Digest Cipher" and has, as Bill Frantz has mentioned, been suggested over twenty years ago. You can find descriptions in the original edition of Applied Cryptography.
> There's no major security issues with this (assuming you use a decent hash function, and I leave *that* as an exercise for you). It is, however, slow and kinda superfluous. If you take the example of SHA-256, you're using its internal block cipher to create a hash function, which is then run twice to create a stream cipher.
> You don't get CFB or OFB this way, those are modes around block ciphers and you're doing something different. Yes, you could do something somewhat analogous, or straightforwardly a way to do essentially  CTR.
> But why? You're getting something much slower than (e.g.) AES in counter mode, and if you were really paranoid you could even do something like Triple-AES. There's nothing wrong with AES-CTR.
> 	Jon

Using something else than djb ciphers or AES is usually beneficial when 
cascading a set of algorithms. The goal would then be to use different 
cryptographic primitives in case one fails. Not trusting AES but 
trusting NSA's SHA256 seems a bit weird, both because of the author and 
because IIRC, early hash functions have a messy design.

I'm not entirely sure why three layers of AES256 are more secure than 
one. If the algorithm is not secure (meaning there is a method to break 
it in polynomial time), wouldn't the amount of security only increase by 
three-fold? Using another cipher based on some other primitive that 
happens to not be broken would actually be secure, right?


More information about the cryptography mailing list