The advice means do not invent algorithms, protocols or constructions, and do not reimplement existing ones. It does not mean you never touch cryptography. You choose and configure vetted libraries, and the main risk is in the glue code: modes, nonces, key handling, comparisons and error paths.
What counts as rolling your own
- Inventing a cipher, hash or MAC, or tweaking one by adding rounds or XOR steps.
- Designing a custom scheme from parts, such as a homemade way to combine encryption with a checksum.
- Reimplementing AES, RSA or a signature algorithm because a library felt heavy.
- Writing your own token format, login handshake or key exchange.
- Hand-rolled password hashing, such as repeated SHA-256 with a salt.
Experts break their own designs, which is why public analysis over years is the safeguard that matters. A construction without that history has not been tested, however clever.
What you are allowed to do
- Pick a well-reviewed high-level library and use its default recommended calls.
- Compose standard pieces in standard ways, for example an AEAD, a KDF and a CSPRNG, following a published recipe such as OWASP's guidance.
- Write the application logic around crypto: where keys live, who can use them, when to rotate.
Where teams still get hurt
Most real failures are in usage, not in the algorithm:
- Wrong mode, such as ECB.
- Reused nonces. See AES-GCM nonce reuse.
- Keys in source control or environment variables.
- Fast hashes for passwords.
- Insecure random sources for tokens.
- Disabled certificate checks.
- Plain equals on secrets.
A good library reduces these by making the safe choice the easy one. Prefer libraries that expose high-level operations such as "seal" and "open" over ones that expose raw block operations.
A review checklist
- Is every algorithm a named, standard one with a current recommendation?
- Is each key generated by a CSPRNG and stored away from the data?
- Is every message authenticated, not just encrypted?
- Are nonces and salts handled by the library or by a documented rule?
- Do comparisons use constant-time functions?
- Can you swap the algorithm later? See designing for crypto agility.
- Does a second person who knows cryptography review any new use?
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each result names the exact place to fix.
Quick check
Is it wrong to implement a standard algorithm from its RFC?
For production, yes in most cases. Subtle bugs like timing leaks hide in correct-looking code, so use a maintained, tested library.
Who should approve new uses of crypto?
Make it a design review item with a named reviewer, so changes beyond library defaults get a second look.
Sources
Last reviewed: 19 October 2026.
