Best practices · Security
Cryptography Best Practices for Developers
Opens with creditsA practical cryptography guide for application developers, not cryptographers. It covers choosing the right primitive and a high-level library, authenticated encryption and nonces, secure randomness, key management with KMS and rotation, TLS configuration, and how to prepare for post-quantum algorithms with crypto agility.
Written by Tauseef Fayyaz6 chapters, 24 practicesAbout 28 min23 quiz questionsReviewed 13 October 2026What you will learn
6 chapters · about 28 min
1Choosing the right tool and libraryBefore writing any crypto code, decide which property you need (secrecy, integrity, authenticity) and use a high-level library that gives you exactly that.4 practices · 5 min
2Encrypting data with AEADAuthenticated encryption keeps data secret and detects tampering in one step. Most of the risk sits in nonces, associated data and how you encrypt with public keys.4 practices · 5 min
- Randomness, tokens and key derivationKeys, nonces, tokens and IDs are only as strong as the random numbers behind them. This chapter covers where to get randomness and how to derive keys from other keys.3 practices · 3 minOpens with credits
- Key management and rotationEncryption moves the problem from protecting data to protecting keys. This chapter covers where keys live, envelope encryption, cryptoperiods and rotating without downtime.4 practices · 5 minOpens with credits
- TLS configuration for servers and clientsTLS protects data in transit, but only with sound protocol settings, well-managed certificates, and clients that actually verify what they connect to.5 practices · 5 minOpens with credits
- Post-quantum readiness and crypto agilityNIST has standardized the first post-quantum algorithms. This chapter covers what changed, what did not, and how to make your code ready to swap algorithms.4 practices · 5 minOpens with credits
About this guide
Most cryptography failures in real applications are not broken algorithms. They are a nonce reused with AES-GCM, a token generated with Math.random, a key hard-coded next to the data it protects, a TLS client with certificate checks switched off "for testing", or a home-made scheme that hashes when it should sign. Cryptography best practices for developers are mostly about choosing well-tested building blocks and using them the way their authors intended.
This guide is written for people who build apps and APIs. It starts with picking the right tool for the job (hashing, encryption, MACs or signatures) and a high-level library such as libsodium or Tink, so you are not assembling primitives yourself. It then covers authenticated encryption and nonce rules, randomness, key management and rotation with a KMS or HSM, TLS settings for servers and clients, and the post-quantum transition: what NIST finalized in FIPS 203, 204 and 205, and what crypto agility means for code you write today.
The advice follows NIST SP 800-57 on key management, NIST's post-quantum cryptography project, the OWASP Cryptographic Storage and Transport Layer Security cheat sheets, the TLSRef server-side TLS profiles, and the libsodium and Tink documentation. Password hashing and secret storage have their own guides on Sefism, so this one only points to them.
Common questions
Should I use AES-GCM or ChaCha20-Poly1305?
Both are sound AEADs with 256-bit keys. AES-GCM is fast on CPUs with AES hardware and widely supported by cloud KMS and Web Crypto; ChaCha20-Poly1305 is fast everywhere. If you want random nonces with no practical message limit, libsodium recommends XChaCha20-Poly1305 with its 192-bit nonce.
What is the difference between hashing and encryption?
A hash is a one-way fingerprint with no key; anyone can compute it and nobody can reverse it. Encryption uses a key and is meant to be reversed by whoever holds that key. For proving who sent data you need a MAC (shared key) or a digital signature (private key), and for passwords you need a slow password hash such as Argon2id.
How often should I rotate encryption keys?
NIST SP 800-57 suggests an originator-usage period of up to 2 years for symmetric data encryption and key-wrapping keys, with older data still decryptable for up to 3 more years. Rotate immediately on suspected compromise, when someone with access leaves, or when usage limits such as message counts approach. Cloud KMS automatic rotation makes the scheduled part routine.
What is envelope encryption?
Data is encrypted locally with a data encryption key (DEK), and the DEK is encrypted with a key encryption key (KEK) that stays in a KMS or HSM. The wrapped DEK is stored with the data. It keeps KMS calls small and rare, and rotating the KEK only means rewrapping DEKs.
Do I need to do anything about post-quantum cryptography now?
Start with an inventory of where you use public-key cryptography, and enable hybrid key exchange such as X25519MLKEM768 in TLS where your stack supports it, because recorded traffic can be decrypted later. NIST finalized ML-KEM, ML-DSA and SLH-DSA in FIPS 203, 204 and 205 in August 2024 and plans to remove quantum-vulnerable algorithms from its standards by 2035.
Which TLS versions should a server support?
TLS 1.3, plus TLS 1.2 with ECDHE and AEAD cipher suites for compatibility. TLS 1.0 and 1.1 are deprecated by RFC 8996 and should be disabled, along with SSLv2 and SSLv3.
Sources (8)
Checked against these, last on 13 October 2026.
- Cryptographic Storage Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
- Transport Layer Security Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
- SP 800-57 Part 1 Rev. 5: Recommendation for Key Management, Part 1: General, NISTcsrc.nist.gov/pubs/sp/800/57/pt1/r5/final
- Post-Quantum Cryptography project, NISTcsrc.nist.gov/projects/post-quantum-cryptography
- NIST Releases First 3 Finalized Post-Quantum Encryption Standards, NISTwww.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
- Server-Side TLS guidelines, TLSRefdocs.tlsref.org/server-side-tls
- Authenticated Encryption with Additional Data, libsodiumdoc.libsodium.org/secret-key_cryptography/aead
- Keysets, Tink docsdevelopers.google.com/tink/design/keysets
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
Checklists
See all- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com