I am working on a Block Storage system, where I have the need to encrypt and authenticate blocks by a client, but also want the server to be able to detect bit corruption while minimizing the work done on the data. The storage blocks are roughly 1MB segments.

One option is to let the client use a AE(AD) cipher (like AES/GCM) and afterwards add a strong checksum. Since AES/GCM is not yet the most optimized cipher (in my Java world), an alternative would be to use a more traditional encrypt-then-HMAC. However, with a normal HMAC, this could not serve as a publicly verifiable checksum. And calculating both, a HMAC and a checksum would double the amount of work which needs to be done (over the message). What about only calculating the checksum over the message, and using a HMAC on this reduced data set?

encrypted = AESCBC(IV, plaintext-1MB)
checksum = SHA224(ID | IV | len | encrypted)
sig = HMAC(ID | len | checksum)
message = ID | IV | len | encrypted | checksum | sig

In this case I calculate a publicly verifiable checksum over the data (so I can detect corruption on the server) and only the client could check in addition to that the HMAC authenticator added. The HMAC does not need to run over all the encrypted data, but uses the checksum as a shortcut. The ID is unique for each segment.

In my case the protocol can't be used as an anonymous oracle and the plaintext length can not be extended boundlessly, however a hash which is more resistant against extension attacks is intentionally used.

I haven't seen much analysis on using ordinary hashes for content authentication. Can anyone can give me a pointer on whether this is safe? (I haven't yet done performance analysis yet; I might simply go with AES/GCM+SHA if that is fast enough). Or is there a more standard construction for generating a publicly verifiable and authenticating tag?


I haven't seen much analysis on using ordinary hashes for content authentication. Can anyone can give me a pointer on whether this is safe?

With good choice of primitives it is. Public key signatures use a hash function in a similar way to identify the message signed.

However, where a MAC only needs what amounts to second preimage resistance, a hash function also typically needs collision resistance, since an attacker can calculate an arbitrary amount on their own. (This is why SHA-1 is being deprecated in signatures even though there's no indication it isn't preimage resistant.)

HMAC is also stronger than the hash function it uses. So while SHA-224 is strong, you will have lower security with it than with HMAC-SHA-2. Technically, it may mean you don't even have 128-bit security – "only" 112-bit.

You don't actually need to use the checksum itself in the HMAC. You can instead use a full SHA-256 (or SHA-512, which may be faster). If you want to truncate – length extension attacks aren't an issue because of the HMAC – only truncate it when writing the checksum, but not when calculating the HMAC. Assuming you don't need as much confidence when detecting corruption, you could even truncate the checksum to only a few bytes and save some space.


hash = SHA-NNN(ID | IV | len | encrypted)
checksum = truncate(hash)
sig = HMAC(ID | len | hash)
message = ID | IV | len | encrypted | checksum | sig

(Having ID and len in the HMAC seems unnecessary, but doesn't hurt.)

| improve this answer | |
  • $\begingroup$ Thanks for the answer, it basically describes my understanding. I am not sure about the "extension attacks arent an issue because of HMAC". It is true that HMAC is designed to resist them, however the HMAC is not applied to the variable size ("encrypted") chunk. Thats why I have included the "len" into the HMAC body. $\endgroup$ – eckes Jul 22 '14 at 12:14
  • 1
    $\begingroup$ @eckes, I say LEA isn't an issue because even if you can derive a hash for a longer message, you will not get it signed by the HMAC. Also, all the data over which the hash is taken in public, so you can just calculate a new one for a modified message – if it was a problem you'd be screwed anyway. $\endgroup$ – otus Jul 22 '14 at 12:18
  • $\begingroup$ Hm, the problem of the extension attack is finding a longer message with the same hash (at least that was my understanding). This is easy for hashes like SHA-1 because the hash itself reveals all the internal state of the hash. (The hash could be recalculated with the malicious data, but it wont be accepted by the HMAC then, but it will be accepted by the HMAC if it hasnt changed.) $\endgroup$ – eckes Jul 22 '14 at 12:21
  • 1
    $\begingroup$ @eckes, in a length extension attack you derive the hash of a longer message from that of a shorter, without knowing the shorter (fully). It will not give you the same hash, or the hash function would not be second preimage (nor collision) resistant. $\endgroup$ – otus Jul 22 '14 at 12:23
  • $\begingroup$ ah yes, right. I was confusing that outcome. $\endgroup$ – eckes Jul 22 '14 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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