Solución:
CBC y GCM son bastante diferentes. Ambos son seguros cuando se usan correctamente, pero CBC no es tan paralelizable y carece de autenticación incorporada. Debido a esto, CBC solo es realmente práctico para cifrar archivos locales que no necesitan acceso aleatorio.
En cuanto a las ventajas que podría tener, CBC no falla tan catastróficamente si se reutiliza el IV, y puede ser más rápido si se implementa en hardware básico.
En cuanto a GCM, es básicamente GCM = CTR + Autenticación (no CBC). Es rápido y seguro si se usa correctamente y muy versátil, de ahí su popularidad.
- CBC es más antiguo, lo que significa más compatibilidad y solo razones históricas generales.
- Hay ventajas de rendimiento, si no necesita GCM para la autenticidad. A menudo, es posible que desee su propio sistema de autenticidad con algunas características adicionales o puede que no lo necesite en absoluto.
Gran nitpick:
GCM = CBC + Autenticación.
No, GCM = CTR + Autenticación.
Pero en general tienes razón; CBC es un modo más antiguo que se inventó en la edad oscura criptográficamente hablando (a más tardar en la década de 1970), y ahora está desfavorecido debido a la falta de autenticación incorporada y todos los problemas que han causado los oráculos de relleno. Un buen ejemplo práctico de esto es que TLS 1.3 eliminó el soporte para CBC.
Sin embargo, GCM tampoco es una panacea. Es estrictamente hablando correcto, pero ha demostrado estar lejos de ser infalible en la práctica:
- Falla espectacularmente si reutilizas un nonce. Un solo nonce repetido permite a un adversario recuperar su subclave de autenticación, además de aprender el XOR de los dos mensajes con el mismo nonce.
- Sus nonces son incómodamente cortos (96 bits), lo que puede ser complicado de usar con nonces aleatorios.
CBC no tiene estos problemas. Los IV aleatorios funcionan bien (y de hecho son obligatorios), y si repite un IV, no obtiene una falla catastrófica, solo filtra información sobre prefijos de texto plano iguales.