Cryptography occupies an unusual place in security. Most engineers know it is important. Most engineers can describe encryption at the level of "the data is scrambled with a key." Far fewer can defend a specific algorithm choice, justify a key length, explain why one mode of operation is appropriate and another is not, or assess whether a particular implementation has the properties they assume it does. Cryptography is the area where confident engineers are most often wrong, because the failure modes are subtle and the consequences are silent until they are not.
Symmetric Encryption: AES Done Right
AES-256 is the safe default for symmetric encryption. The complications start with mode of operation. AES in ECB mode is broken for any meaningful purpose — identical plaintext blocks produce identical ciphertext, which leaks structure. AES in CBC mode is acceptable for some applications but requires careful padding handling and is vulnerable to padding oracle attacks if implemented carelessly. AES-GCM provides authenticated encryption — confidentiality and integrity together — and is the modern default for most use cases. Distinguishing between these modes is one of the most common gaps in engineer-level cryptography understanding.
Asymmetric Encryption and the Right Tool for Each Job
RSA, elliptic curve cryptography, and Diffie-Hellman key exchange each solve different problems. RSA is widely used for digital signatures and key encapsulation but at the key sizes required for modern security (2048+ bits, more often 4096) it is computationally expensive. Elliptic curve cryptography provides equivalent security at much smaller key sizes — Curve25519 for key exchange, Ed25519 for signatures are common modern choices. Diffie-Hellman (and its elliptic curve variant ECDH) handles key exchange specifically. Engineers who treat all asymmetric crypto as interchangeable typically end up with implementations that are either insecure, slow, or both.
Hashing Versus Encryption Versus Encoding
Three concepts that get confused in code reviews more often than they should. Hashing is one-way — there is no inverse. Encryption is reversible with the right key. Encoding is reversible without any key (Base64 is encoding, not encryption). Using a hash where reversibility is needed, encryption where uniqueness is needed, or encoding where confidentiality is needed are all common bugs that pass code review when reviewers do not distinguish between the three.
Password storage is the most consequential application of this distinction. Passwords should be hashed with a key derivation function specifically designed for passwords (Argon2, scrypt, bcrypt) — not encrypted, not hashed with SHA-256 directly. Engineers who reach for SHA-256 for password storage produce systems that look secure to other engineers and are trivially attacked at scale. The certification material covers this; the field still gets it wrong regularly.
Key Management: Where Most Implementations Fail
Strong cryptography with weak key management produces the same outcome as weak cryptography. Keys need to be generated with adequate entropy, stored securely (HSM, key management service, OS keystore), rotated on a defined schedule, and destroyed when no longer needed. The boundaries between key generation, storage, distribution, use, and destruction are where security is won or lost. Hardcoded keys in source code, keys committed to repositories, keys logged inadvertently, keys used past their intended lifetime — all of these are common, and all of them undermine cryptographic protection regardless of algorithm strength.
TLS in Production
- TLS 1.3 wherever supported; TLS 1.2 with strong ciphers as a fallback only
- Certificate validation enforced — disabling validation in production is a recurring vulnerability
- Certificate pinning where appropriate, with operational discipline to handle rotation
- Modern key exchange (ECDHE) and authenticated encryption (AES-GCM, ChaCha20-Poly1305)
- Forward secrecy as a deployment requirement, not a nice-to-have
Why a Cryptography Credential Pays Back
Most security engineers can be productive without deep cryptography knowledge — until they hit a problem that requires it. Designing a new authentication protocol, implementing data-at-rest encryption with key escrow requirements, building a hardware security module integration, evaluating a vendor cryptographic claim, responding to an audit finding about cryptographic strength. The Certified Encryption Specialist credential or equivalent training provides the depth needed for these conversations. The credential is not the goal; the credential is the proxy for the depth.