What are some ways to ensure that a cryptography library is reliable in an ecosystem that is new to me?

Question

Cryptography is a core security service, and is generally considered a specialty that is difficult to get right unless one knows what they are doing. Furthermore, cryptography API misuse is rampant and the cause of many security vulnerabilities. This question refers to using Cryptography libraries as a software developer.

In any given language, say Python, for example, I am looking for a reasonable way to determine which librari(es) is most suitable for use from a security standpoint. I've heard of and seen pages for pycryptodome, pycrypto, cryptography, PyOpenSSL, libnacl, python-nss, etc... There are also many libraries like this for other languages.

It is not immediately clear to me or another non-ecosystem-veteran, which of these libraries is the most updated, secure, backed one. Obviously, in cases where all of the cryptography services are built into a language's standard library, this is less of a problem. A few ideas I've had is simply checking the GitHub pages for how updated and well-maintained the repository seems to be, however, this is only one aspect and if I'm shown 5 repositories that are all updated and maintained, I'm somewhat back to square one. Another thought was try to research the main developers, ensure the code is signed, etc... But this also isn't always easy as some go by screen names, etc... It would seem to me that there would need to be a quite reliable way to determine "this is a safe, vetted, crypto library." After all, a single line of malicious or naively written code could compromise an entire cryptosystem.

Answer 1

... ensure that a cryptography library is reliable

I don't think this is specific to cryptography. This kind of question can be asked about any kind of software dependency, because any of these might introduce security issues into the code. And similar questions are asked outside of software development and security too, because a reliable supply chain is important everywhere.

Since most are lacking the experience and/or time to thoroughly evaluate a software component, it is probably the best to rely on the collective experience of others. Thus use the same libraries as widely known and critical software projects use. This does not mean that all the software components which are used there are safe to use, but the chance is higher that more people care about having stable and secure dependencies. This results in more time, money and experience spend to evaluate such critical dependencies and to maintain these.

... cryptography API misuse is rampant and the cause of many security vulnerabilities

This is a different topic than the reliability of the component itself. This is instead about how easy it is to use the component in a safe way. Some components offer a safe and small API for common tasks. Other offer lots of flexibility instead which usually goes together with more complexity and more ways to do things wrong by mistake. Thus the choice not only depends on the reliability of the library itself but also how much flexibility you actually need and on the competence of your own developers to handle such flexibility in a safe way.