The main issue with AES-CBC+HMAC (besides speed), is that unless you're using a library that offers a complete primitive that combines these algorithms[1], you

The main issue with AES-CBC+HMAC (besides speed), is that unless you're using a library that offers a complete primitive that combines these algorithms[1], you will have to combine the encryption and MAC yourself. In this case, you will have to know, that the only safe way to do this with is Encrypt-then-MAC, and you'll also have to remember to do (and in some languages know how to implement!) a constant-time comparison for the HMAC value. Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right, IMHO, to avoid mentioning AES-CBC+HMAC. Yes, it can be implemented safely. So does RSA for that matter. But is it likely that most developers (or let's be generous - even more than 10% of them) will implement this correctly? No. When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that. WireGuard implements its own transport and TarSnap implements its own crypto (on top of RSA, no less!) and you don't see the authors of these documents criticizing them. In fact, TarSnap is consistently recommended in this guide. But the audience for these best practices is not Colin Percival[2]. It's the average developer who usually has an "Intro to Cryptography" background from their CS Major at the best of times. [1] I am not aware of any audited library that does this, but Google's Tink offers AES-CTR+HMAC: https://developers.google.com/tink https://developers.google.com/tink [2] https://en.wikipedia.org/wiki/Colin_Percival https://en.wikipedia.org/wiki/Colin_Percival