Do you have any hard evidence that somehow mandating a "cryptography course" fixes this?

My guess is that it doesn't help and might even make things worse because now they'll think "Don't roll your own" was an instruction to plebs who didn't take that one semester cryptography course at school.

The cryptography course in my bachelor's was good enough to paint a picture of the complexity involved. By then I had already heard the "don't roll your own crypto" mantra, so maybe that primed me, but the semester course helped to get an appreciation for the subtle ways information leaks when you try to contain it. It also gave me some more confidence to push back if for example a colleague tried to convince me that the mantra doesn't apply to them/us.

Obviously you can't mandate a high quality course into existence, but I definitely good value out of having it in the required curriculum.

My primary takeaway from the cryptography course I took was a good understanding of why I shouldn't try to roll my own crypto, but a lot of that came down to the course design. Mine spent significantly more time on covering how various cryptography schemes were broken than on how to implement things, and a course which was the other way around could easily inspire false confidence.

I've seen crypto papers (and cited!) that are worse than this advice. Not sure what you are trying to say here.

Speaking as someone that has both broken crypto systems and designed ones that got broken (internally, in review, before they made it out), it takes a lot of practice to become proficient at cryptography. Sometimes a little bit of knowledge is worse than none at all.

The problem with repeating "don't roll your own" is that you're also going to cock up implementing someone else's solution.

I would disagree. I learned the basics and done things like cryptopals and that was enough to be aware of everything in this post. At the same time, I understand the threshold of things I shouldn't touch much better. With the right curriculum, you can focus on the non-dangerous ideas, rather than spending time on the math behind RSA like my uni course did. (And ended up practically useless)

You don't need to be proficient at cryptography to be aware of the common attack classes and reasons we use prepackaged things like NaCl before going low level.

Software engineers should be made aware of such pitfalls, but I don't think a whole course is necessary or useful. It's very easy to build encryption that you can't crack, especially because the "types of attacks" is a truly endless font.

It's probably more useful to have a module within a course to discuss the current state of the art and learning some history about how the methods were chosen (e.g. NIST's AES, SHA2/3, and PQC open processes. I think making it very obvious that there are extremely good, quality, free tools out there would reduce the likelihood of someone DIYing some crap.

That said, I once spec'd using Ed25519 asymmetric signatures for webhooks sent out to customers, and later on one of our Elixir developers was complaining that the throughput was garbage. I was confused because https://ed25519.cr.yp.to/ boasts signing rates of ~27k/sec/core on very old hardware. Turns out they were using some "pure Elixir" library which had shit (over 1000x worse) performance. There wasn't any real surface area for attacks here, but there are plenty of devs who will blindly search package-manager-of-choice for an otherwise good encryption and get screwed. Not sure who blame in that scenario.