¿Hay casos en los que se prefiera AES CBC + HMAC en lugar del modo AES GCM?

GCM tiene algunas ventajas, por un lado, permite el procesamiento paralelo, lo que lo hace eficiente y utilizable para operaciones de hardware simultáneas. Dado que compara GCM con CBC + HMAC, le indicaré la extensión GCM GMAC. GMAC es la variante HMAC, pero en su lugar utiliza un campo de Galois.

Un campo de Galois predefinido, digamos GF (2 ¹²⁸ ), se puede calcular de manera independiente sobre un polinomio, mientras que el CBC encadena bloques basándose en resultados anteriores. Esto le da a GCM un alto rendimiento y lo hace muy eficiente.

Sí, hay algunas ventajas para CBC-HMAC sobre GCM. O más bien, hay algunas desventajas de GCM .

GCM se vuelve más vulnerable cuando el tamaño de la etiqueta de autenticación es más pequeño. La seguridad de GCM también se descompone completamente en la reutilización de nonce, lo que la hace menos útil para los usuarios que no son aleatorios, especialmente cuando el generador de números aleatorios no es tan seguro como le gustaría que fuera.

Como se menciona brevemente en el enlace, también existen argumentos de implementación y seguridad contra GCM.

También puede usar el modo EAX también, aunque el NIST no ha estandarizado oficialmente ese modo. EAX utiliza AES-CMAC para calcular la autenticidad, por lo que solo depende de un AES rápido para estar disponible. Tiene una interfaz AEAD similar a la de GCM: es incluso un poco más flexible cuando se implementa correctamente. Pero al igual que CBC + HMAC es un protocolo completo de dos pases. Y luego está el modo OCB, y por supuesto Keccak en modo de cifrado (experimental).

Sí, cuando uno o más de los sistemas que necesitan interactuar no son compatibles con GCM.

Las versiones anteriores de .Net y Windows 2008, por ejemplo, no lo hacen y es lo mismo con algunas pilas de middleware de Java, por lo que si estuviera implementando una solución allí tendría que usar CBC.