I understand that the main motivation for HMAC is extension attacks. If data always has content-length either implicit in the app or even explicitly put into the hash, I get the impression that HMAC is not necessary. The motivation is to allow password based encryption of keys, using widely available primitives, and periodic rotating of master-password without re-encrypting data (but re-encrypting keys):

file.name = "foo.txt"
file.iv = freshRandom256Bits() 
filekey = freshRandom256Bits() #only master learns this
#encrypted key
file.encryptedKey = sha256(masterpwd+":"+file.iv) ^ filekey
#make it hard to forge data
file.auth = sha256(masterpwd+":"+file.owner+":"+file.encryptedKey)
#write data stream and file meta, then filekey goes out of scope
writeEncryptedIO(file, filekey)

In this case, the encryptedKey has a known length. In that case, HMAC is not strictly necessary, no? If I did use an HMAC variant like:

$$h(k || h(k || data))$$

Does it really buy me anything? Is it OK to omit the XOR with constants that are prescribed? I'm under the impression that the whole reason HMAC is good is that it solves the extension problem by making the thing appended to k be of a known length.

  • $\begingroup$ I guess this comes down to reading HMAC related papers to find out why the XOR with the (different) bit strings is necessary. $\endgroup$
    – Maarten Bodewes
    Commented Jun 30, 2016 at 9:55
  • $\begingroup$ @MaartenBodewes ... and if you have done that you can also answer one of our older Qs here: crypto.stackexchange.com/q/15734/23623 $\endgroup$
    – SEJPM
    Commented Jun 30, 2016 at 21:15
  • $\begingroup$ @SEJPM There is little wrong with the deleted answer to that question, Wikipedia claims that "The values of ipad and opad are not critical to the security of the algorithm, but were defined in such a way to have a large Hamming distance from each other and so the inner and outer keys will have fewer bits in common. The security reduction of HMAC does require them to be different in at least one bit.[citation needed]". So it's a question of finding the security reduction of the HMAC function. Note that algorithms can be secure without security reduction, just not provably secure. $\endgroup$
    – Maarten Bodewes
    Commented Jun 30, 2016 at 22:15

1 Answer 1


I think the attack by Preneel and van Oorschot (MDx-MAC and Building Fast MACs from Hash Functions, CRYPTO'95) in Proposition 4 applies. It was cited by PulpSpy in reply to my question about H(pass||length(data)||data). With fixed-length data, that amounts to a known suffix for the key.

Proposition 4 states in a nutshell that for a generic construction which generally covers H(…||data||…) where H is an $n$-bit hash function, there is an attack that allows the attacker to replace some trailing blocks. The attack does however require about $2^{n/2}$ known text-MAC pairs, which is not feasible with a 256-bit hash. So this 20-year old result exhibits a theoretical attack. I don't know if there are more recent results that show a more practical attack.

  • $\begingroup$ The reason I ask is that I would have a program that writes encrypted data that has full access to lots of modern primitives. But the data is stored in a database that has little more than sha256 and bytewise xor. When rotating the key, I'd like to have a stored procedure to rewrite all the file keys in a transaction. Also, the MAC, encrypted keys, nor plaintext keys are shared with the user. This is designed to keep a database dump from being useful. $\endgroup$
    – Rob
    Commented Jun 30, 2016 at 23:42
  • $\begingroup$ @Rob If you have SHA-256, xor and concatenation then you can build HMAC-SHA-256. Don't roll your own if you can possibly avoid it, and since you have xor you don't need to skimp. $\endgroup$ Commented Jun 30, 2016 at 23:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.