There is a java library for android which implements integrity checking to predefined encrypting mode(which can be found here).

Short class description from author page to avoid further questions about code.

  • Algorithm & Mode: AES 128, CBC, and PKCS5 padding. We use a 128 bit key size for its widespread support and because it’s not clear that 256 is stronger. We would have picked GCM for its built-in integrity checking, but that’s only available since Android Jelly Bean, which leaves out about 1/4 of active Android devices
  • IV Handling: We securely generate a random IV before each encryption.
  • Key generation: Random or pasword-based.
  • Integrity: We’ve also added more-or-less transparent integrity checking in the form of a SHA 256 MAC with a constant-time equality check. This is in the form of a “combined key” where 128 bits of the key are used for encryption and 256 bits are used for integrity, then the keys are kept together.

As stated before, it's possible to use AES-GCM, which already have built-in integrity checking.

So, the question is: Are there any (dis)advantages of adding external integrity check to AES-GCM (in theory, or practically)?

To sum up already mentioned comments:


  • loosing the speed advantage of AES-GCM;
  • performance/space use and extra complexity(i don't think that complexity is the case, as library is fairly simple);
  • human factor:
    • "Crypto is tricky: it’s hard to tell that the gibberish that’s being printed is not good crypto, and it’s hard to tell that the code example you picked up from {put any source name here you like} has serious flaws."


  • HMAC-SHA256 has stronger authentication than GCM(in-depth explanation here), among other things not leaking the key in case of nonce reuse

Thank you for your answers.

  • $\begingroup$ Possible duplicate of Security of integrity protection with HMAC vs AEAD $\endgroup$
    – otus
    Nov 17, 2015 at 22:03
  • $\begingroup$ That library adds HMAC-SHA256 on top of the cipher so the duplicate I linked should answer your question, at least about the advantage. The disadvantages would be performance/space use and extra complexity. $\endgroup$
    – otus
    Nov 17, 2015 at 22:05
  • $\begingroup$ besides loosing the speed advantage of AES-GCM over AES-CTR+HMAC (or whatever they use)? no, I don't know any. $\endgroup$
    – SEJPM
    Nov 17, 2015 at 22:05

1 Answer 1


Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to stay away from getting creative with protocol design - just use the best-known implementation of the best-known primitive for the job.

  • 3
    $\begingroup$ In a nutshell, using more than the minimum amount of crypto necessary is more likely to weaken security than improve it. $\endgroup$ Nov 18, 2015 at 0:12
  • $\begingroup$ This does not mention any of the advantages. $\endgroup$
    – otus
    Nov 18, 2015 at 12:52
  • 1
    $\begingroup$ What advantages? $\endgroup$
    – pg1989
    Nov 18, 2015 at 16:19
  • $\begingroup$ @pg1989 HMAC-SHA256 has stronger authentication than GCM, among other things not leaking the key in case of nonce reuse. $\endgroup$
    – otus
    Nov 19, 2015 at 8:52
  • $\begingroup$ If you're gonna do two-pass authenticated encryption, why not just CBC+HMAC? $\endgroup$
    – pg1989
    Nov 19, 2015 at 18:39

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.