> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Jakob Bohm > Sent: Tuesday, April 18, 2017 06:22 > > Please note that all of these "CBC vulnerabilities" you specifically > mention are SSL/TLS vulnerabilities in the particular ways that SSL3 > and current TLS versions handle padding and IV management, not > issues with CBC itself. > > Also note that GCM is very much a "marginal" design, operating at the > very edge of what is safe to do and furthermore putting all the > cryptographic "eggs" in one basket (AES and GF-2^n arithmetic). Agreed on both points. Of course with any block cipher operating mode that requires padding you have the possibility of protocol and implementation errors that create padding oracles. But with GCM you have the possibility of, say, implementation errors that lead to nonce reuse. All of the modes have risks. (Also AE / AEAD modes seem like they're on the edge of violating Moxie Marlinspike's Cryptographic Doom Principle: If message integrity isn't the very first thing you check, sooner or later you'll regret it. The CDP isn't scientific, but then neither is cryptographic protocol design. The rush to AEAD modes seems to be largely driven by performance concerns, and that does not make for good crypto. Take TLSv1.3's 0-RTT session resumption, for example.) And for most applications, attacking the crypto isn't a particularly likely mode of attack anyway. There are lower-hanging fruit, and even flawed crypto will direct the attacker's attention elsewhere. Or the nature of the application doesn't provide enough volume or flexibility to exploit a theoretical vulnerability. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
