Is it an overkill to add external integrity check to the AES-GCM encoding?

Question

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:

Disadvantages:

• 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."

Advantages:

• 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.

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.