The first rule of cryptography is do not implement your own. The second rule is choose your library carefully, because the wrong choice can be nearly as dangerous as rolling your own.
Cryptographic libraries vary enormously in quality, security track record, API design, and maintenance status. A library with a well-designed API makes it hard to misuse cryptographic primitives. A library with a poor API makes it easy to encrypt data with a static IV, use ECB mode, or skip authentication entirely.
Selection Criteria
Misuse Resistance
The most important criterion for a cryptographic library is how hard it makes common mistakes. A library that requires you to manually manage nonces, select cipher modes, and handle padding is a library that will be misused.
Good libraries provide high-level APIs: "encrypt this data with this key" without exposing cipher modes, IVs, or padding. The library makes safe choices internally. If you need a low-level API for specific requirements, it should be available but not the default path.
Audit History
Has the library been professionally audited? By whom? When was the most recent audit? Audit reports should be publicly available. A library that has never been audited by an independent security firm should be treated with caution for production use.
Maintenance Activity
Cryptographic libraries need active maintenance. New attacks are discovered regularly, algorithms get deprecated, and implementation bugs need fixing. A library that has not had a release in two years is a liability.
Check the commit history, issue tracker, and release cadence. A healthy cryptographic library has regular releases, responsive maintainers, and a clear security policy.
Side-Channel Resistance
Cryptographic implementations must execute in constant time to resist timing attacks. This is difficult to achieve in high-level languages where the runtime may introduce variable-time operations through optimization, garbage collection, or JIT compilation.
Libraries that are designed for side-channel resistance document their approach and have been tested against timing analysis tools.
Recommendations by Language
Python
PyNaCl / libsodium is the best choice for most Python applications. It wraps the libsodium library, which provides a high-level, misuse-resistant API. Authenticated encryption, key exchange, and digital signatures are all available through simple function calls.
cryptography (the cryptography PyPI package) provides both high-level recipes and low-level OpenSSL bindings. It is well-maintained, regularly audited, and the standard recommendation for applications that need more flexibility than libsodium provides.
Avoid: PyCrypto (unmaintained), PyCryptodome (functional but less audited than cryptography).
JavaScript / Node.js
Node.js built-in crypto module wraps OpenSSL and is the standard choice for server-side JavaScript. The API is lower-level than ideal, so use the crypto.createCipheriv and crypto.createDecipheriv functions with authenticated modes (AES-256-GCM).
libsodium.js provides libsodium bindings for both Node.js and browsers. For applications that need cryptography in the browser, this is the recommended approach.
Web Crypto API is available in browsers and provides hardware-accelerated cryptographic operations. The API is promise-based and reasonably misuse-resistant.
Avoid: any npm package that implements crypto primitives in pure JavaScript without wrapping a proven native library.
Java
Tink (Google) provides a high-level, misuse-resistant API for Java. It handles key management, algorithm selection, and mode configuration internally. This is the best choice for most Java applications.
Bouncy Castle provides comprehensive cryptographic functionality, including algorithms and protocols not available in the standard JCA. The API is low-level and easy to misuse, so it should be used by developers with cryptographic expertise.
JCA (Java Cryptography Architecture) is the built-in framework. It provides adequate functionality but the API design makes misuse easy (ECB mode is the default for Cipher.getInstance("AES")).
Go
Go standard library (crypto/* packages) is well-designed and maintained by the Go team. The API encourages correct usage, and the implementations are carefully written for side-channel resistance.
NaCl/box and NaCl/secretbox in the golang.org/x/crypto package provide high-level authenticated encryption. These are the simplest correct option for most use cases.
Rust
ring is a focused, audited cryptographic library that wraps BoringSSL and provides a safe Rust API. It is used by rustls and other security-critical Rust projects.
RustCrypto is a collection of pure-Rust cryptographic implementations. They are well-maintained but have received less formal auditing than ring.
Common Mistakes to Avoid
Using ECB mode. ECB encrypts each block independently, leaking patterns in the plaintext. Always use an authenticated encryption mode like GCM or ChaCha20-Poly1305.
Reusing nonces. With AES-GCM, reusing a nonce with the same key completely breaks the authentication guarantee and can leak the authentication key. Use random nonces or a counter that is guaranteed to never repeat.
Encrypt without authenticate. Encryption without authentication (using AES-CBC without HMAC, for example) is vulnerable to padding oracle attacks. Always use authenticated encryption.
Hardcoding keys. Cryptographic keys should never appear in source code. Use a key management service, environment variables, or hardware security modules.
Using passwords as keys directly. Passwords must be processed through a key derivation function (Argon2, scrypt, or bcrypt) before use as encryption keys.
How Safeguard.sh Helps
Safeguard.sh monitors your cryptographic library dependencies for known vulnerabilities and deprecated algorithms. Our platform identifies which cryptographic libraries your applications use, tracks their versions against known CVEs, and alerts you to security updates. When cryptographic best practices change (like the deprecation of a cipher or key size), Safeguard.sh helps you identify affected applications across your entire portfolio.