Respectfully, I understand why you give this advice — and it isn't bad advice — implementing crypto correctly is difficult. But OpenSSL, in particular, has not

Respectfully, I understand why you give this advice — and it isn't bad advice — implementing crypto correctly is difficult. But OpenSSL, in particular, has not and is not serving the engineering community well. The defaults are insecure. The bugs are horrendous. The API and tools border on unusable. I would really like to see a crypto library with a good API; I also believe Rust would make a much better language to implement a crypto library in than C, and would serve the community better in the long run. If one agrees that this is the case (a better library needs to be built), then at some point, that project must get underway. While I understand why the rule "crypto is hard. Don't implement your own." exists, at some point someone must break it, no? How should someone go about doing that? Who should go about doing that, since it seems like no matter how much I learn, "don't implement your own crypto"[1] will always apply? Otherwise, we're stuck here with OpenSSL, unable to do anything about it — no? Of course, any new crypto library must fall in the "idiosyncratic" category; perhaps asked differently is there anything a new library could do to earn trust of people like yourself, and gain better acceptance? (e.g., tests?, though I do know that unit tests are not a proof of correctness in implementation.) [1] and by "don't implement your own", I mean exclusively implementing the current state of the art algorithms, such as SHA2, AES, RSA, etc. I do not mean inventing your own algorithms, which is a whole other breed of crazy.