Ignoring that there are far better and more standard approaches to providing authentication and integrity guarantees, what (if any) weaknesses would a system as outlined below that relies on AES (AES/CBC/PKCS7Padding) encryption to produce a MAC suffer from?

plaintext = 12345678|2018-09-18T00:43:27+00:00 (uniqueID + timestamp)

MAC = aes256(sha256(plaintext))

Could you reliably decrypt the MAC, and then compare the output to the hash of the plaintext to prove integrity/authentication. Assuming that the MAC was generated by a trusted source with a shared secret key.

Also assume that an attacker would have access to lots of plaintext and MAC pairs.


  • One issue is that if you use CBC then the MAC is malleable. If you find two messages where the first 128 bits of their sha256's collide you can modify the IV for one to get a MAC for the other. I wouldn't be surprised if the collision is possible as even brute force would only require around $2^64$ trials to find a collision.
    – qbt937
    Nov 3, 2019 at 21:21
  • But if you get rid of the IV and just output the last block from CBC then what you describe is equivalent to SHA256 followed by CBC-MAC. This is provably secure.
    – qbt937
    Nov 3, 2019 at 21:24
  • Oops, I should have said that the second 128 bits collide, not the first.
    – qbt937
    Nov 4, 2019 at 0:58

1 Answer 1


A signature is created with a secret private key and verified with a public key. What you're talking about is a MAC, which is created and verified with the same key.

If you want to create a MAC with AES, then there's already a standard algorithm for that. It's called CBC-MAC, and it basically involves encrypting the plaintext using CBC mode and using the last block as the MAC (but be wary of pitfalls).

If you want to create a MAC using a hash like SHA-256, you're much better off using HMAC, as it's a standard algorithm with provable security properties (assuming certain things about the hash, but even MD5 is still very secure when used with HMAC).

aes(sha256(plaintext)) might be ok, but don't roll your own! If you really want to show something wrong with it, you could try pointing out that it's non-standard and relies on the security of both AES and SHA-256, whereas HMAC-SHA256 is standard and relies only on the security of SHA-256.

  • Yes, I agree using HMAC would be far more appropriate. Unfortunately trying I'm to prove that exact fact to someone and I'm at the limit of my understanding with regard to how exploitable aes(sha256(plaintext)) is and was hoping for some concrete examples. I'll also update my question to refer to a MAC not a signature due to the symmetric nature. Thanks.
    – joedoe
    Sep 18, 2018 at 1:23
  • 1
    In that case I'll vote to move to crypto.se, as you may get better answers there. The best I can give you is that it's non-standard and needlessly relies on both AES and SHA-256, instead of just SHA-256. Sep 18, 2018 at 11:53

You must log in to answer this question.

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