First off: I know that encrypt-then-authenticate is better, however I want to understand the following for authenticate-then-encrypt. The underlying cipher is AES-CTR or AES-CBC for this consideration.

When using encrypt-then-authenticate, the authenticity of the of the cipher text can be proven, because both parties have the key for the authentication algorithm, e.g. HMAC.

When using authenticate-then-encrypt, one party can't prove the authenticity of the cipher text, as it has to decrypt it first. If it decrypts and then checks the authenticity digest and gets a match, then it knows, that the message has authenticity.

And here is my question: does an algorithm for authenticity, e.g. HMAC, that uses a key, provide anything more than the integrity a simple checksum like CRC-xx can also provide? If a party decrypts a message and gets a match on the checksum, that should mean, that the correct key was used, that only the two parties have and therefore authenticate the message.

Thanks in advance and BR.

1 Answer 1


It seems you are asking: If the receiver can correctly decrypt the message using the secret key, isn't that proof already that it was sent by the other party which also has the secret key?

AES and similar block ciphers don't really make distinction between succesful and failed decrypt operations. A message is transformed in a certain way, and that hopefully results in the plaintext. So we would need to check the embedded HMAC or CRC checksum to see whether the decryption succeeded.

An attacker would be able to manipulate the ciphertext so that the CRC is correct for the plaintext.

With certain ciphers, such as AES-CBC, an attacker can change the ciphertext in a manner that reliably changes the plaintext. If an attacker would modify the ciphertext, our HMAC or CRC checksum would no longer be correct. However, for a CRC checksum, the attacker can modify the ciphertext until the CRC is correct again. The attacker can flip bits in the embedded CRC, and can calculate what it should be.

  • Your blog article helped, thank you. To the modification of CRC checksum: is this only an issue for low entropy variants, like CRC-8 or CRC-16, or is using CRC-64 fine? As far as I understand it, HMAC would still only provide integrity by its length and no useful additional authenticity.
    – earthling
    Commented Feb 15, 2021 at 13:39
  • 2
    See moxie.org/2011/12/13/the-cryptographic-doom-principle.html for some interesting reading on this subject.
    – mti2935
    Commented Feb 15, 2021 at 14:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .