> BRB, going to go roll my own AES -- what could possibly go wrong?
Probably not much more than picking an AES library written from someone else.
It's fairly unlikely that your custom AES would function at all unless it was functionally correct.
Your bespoke AES will likely have timing sidechannels, but so will most AES you go pick off the shelf. (in fact, if you happen to need CBC mode, virtually any AES you pick off the shelf will end up having timing side-channels, because most code that doesn't is GCM only)-- particularly because it's hard to be both high performance and side-channel free without using SIMD, and to do that you need to operate on multiple blocks at a time.
In fact, since you happen to know your environment is targeting only hardware with AES-NI (in my hypothetical), you'll just use that and you'll even be free of side-channels too.
The "abstinence only cryptography" advice was originally about inventing your own blockciphers and such, not implementing existing ones.
Okay so you're smart and so you'll want to go take your AES from some highly reviewed sourse with lots of smart people. You pick.. say.. the Linux kernel. Welp if you picked the plain C implementation in it, congrats, you just got yourself a bunch of timing side-channels.
There are, of course, plenty of things that can go wrong in making your own implementations-- so it's not entirely misplaced to apply it to implementations-- but sadly you are not more likely to avoid them by simply picking one written by someone else. If you understand the domain then you can select a good library and evaluate it, but if understand that you could likely also write your own. :(
On the plus side, a simple blockcipher isn't the sort of dependency that is likely to have a substantial on-going cost either. It won't randomly change its behaviour (we hope, at least not until haxors take over the upstream repository), its functionality is simple and well specified, etc.
So it is probably fine to use one from a library and the OP's advice doesn't apply. But all the reasons why the code you wrote would probably be broken? They probably still apply to the library.
Eh. Yes, more likely, though unless you're talking about something with openssl level ubiquity it might not do much.
For example: my post pointed out that Linux's naive AES has a huge timing sidechannel (e.g. the same bug JoeBob's would). This isn't news. It's also not fixed.
Many times I've been asked to review a cryptographic library and found that it had problems, had them for been for years.. Sometimes the issues had been reported and just ignored.
In some cases reporting the issue just causes the author to take it down... creating its own problems for people who were depending on it!
At the moment I have two private outstanding bug reports for total breaks in cryptosystem library code that I just stumbled into while browsing the internet where the authors/maintainers haven't replied and it's been more than a month. After a bit longer, I'll make the reports in public, but I expect the software will continue to go uncorrected (or just be taken down in response).
One piece of advice I'd give for anyone taking a dependency: go read through its bug tracker of open bugs (and recently resolved ones) -- and their public patch queue if they have one. Also do the same for all transitive dependencies. You can gain some pretty valuable knowledge and more benefit from shared bug finding.
Of course, if you're not a subject matter expert you might not be able to judge if a report is correct or if the subject is serious-- though you will probably be able to tell if the maintainers are active/responsive.
I gave a talk once on the problem of "Selection Cryptography"-- where I argue that merely _picking_ an implementation of cryptographic code (much less the primitives to use) is an act of rolling your own cryptography that triggers similar risks to writing some which also must be managed.
