Cryptography Glossary for Engineers - AES, RSA, ECDSA, HKDF, Envelope Encryption, and TLS Explained

First Published:
Last Updated:

This glossary defines the essential terms that engineers building or operating systems with cryptography meet on the job — from picking AES-GCM versus ChaCha20-Poly1305 for a new service, to wiring up an HKDF key schedule, to understanding what AWS KMS actually does behind GenerateDataKey. Each entry is short (two to four sentences), names the closest related terms, and links to the canonical NIST, RFC, IETF, or AWS KMS documentation page so you can verify the definition or follow up on details. The 85 entries are grouped into nine categories — symmetric encryption, asymmetric and public-key cryptography, hash functions and MACs, key derivation and password hashing, AEAD and mode primitives, forward secrecy and post-quantum, key management and envelope encryption, PKI and certificates, and TLS — and a full A–Z index is provided at the top for direct jumps.

The glossary is designed as a single-fetch reference: an AI search agent (or a human reader) can answer a "what is X in cryptography?" question without having to open every individual NIST FIPS or RFC. For deep dives, follow the internal links to companion articles on hidekazu-konishi.com listed at the end. The topic is universal — the same terms are used across TLS, SSH, JWT, code signing, and the major cloud KMS offerings — so a reference like this does not go stale the way a service-specific snapshot does.

Out of scope: pricing numbers (AWS KMS request and key-storage prices change frequently), step-by-step API request and response examples, and any non-public deployment configuration. Algorithm names use their canonical, vendor-neutral spelling (e.g., ECDSA, not "AWS KMS ECC_NIST_P256"); the AWS-specific spec name is mentioned only where the deployed surface differs from the standard.

How to Use This Glossary

Each term entry has three lines: a short definition that stands on its own (no forward references), a Related: line that lists 2–6 nearby terms in this same glossary as in-page anchors, and a Source: line that links to the most authoritative public document — usually a NIST FIPS publication, a NIST Special Publication, an RFC, or the AWS KMS Developer Guide.

Algorithms that are widely deployed but no longer recommended (MD5, SHA-1) are included so you can recognize them in legacy systems, with the entry explicitly labelled (legacy). New deployments should use the modern alternatives named in the Related: line.

A–Z Index of 85 Terms

The full list, in alphabetical order, with anchors to each entry:
  1. 0-RTT (Zero Round-Trip Time Data)
  2. AEAD (Authenticated Encryption with Associated Data)
  3. AES (Advanced Encryption Standard)
  4. AES-128
  5. AES-192
  6. AES-256
  7. ALPN (Application-Layer Protocol Negotiation)
  8. Argon2
  9. Authentication Tag
  10. AWS CloudHSM
  11. AWS KMS Customer Managed Key
  12. AWS KMS Encryption Context
  13. AWS KMS Multi-Region Key
  14. bcrypt
  15. BLAKE3
  16. Block Cipher
  17. BYOK (Bring Your Own Key)
  18. CA (Certificate Authority)
  19. CBC Mode
  20. CCM Mode
  21. Certificate Chain
  22. ChaCha20-Poly1305
  23. Cipher Suite
  24. CMAC
  25. Constant-Time Comparison
  26. CRL (Certificate Revocation List)
  27. Cryptographic Hash Function
  28. CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
  29. CSR (Certificate Signing Request)
  30. CTR Mode
  31. Curve25519
  32. DEK (Data Encryption Key)
  33. Diffie-Hellman (Classical)
  34. ECB Mode
  35. ECDH (Elliptic Curve Diffie-Hellman)
  36. ECDSA
  37. Ed25519
  38. EdDSA
  39. Encrypt-then-MAC
  40. Envelope Encryption
  41. FIPS 140-2 and FIPS 140-3
  42. Forward Secrecy (FS)
  43. GCM Mode
  44. GMAC
  45. HKDF
  46. HKDF-Expand-Label
  47. HMAC
  48. HSM (Hardware Security Module)
  49. Intermediate CA
  50. IV (Initialization Vector)
  51. KEK (Key Encryption Key)
  52. Key Rotation
  53. Key Wrap (RFC 3394)
  54. KMS (Key Management Service)
  55. MD5 (legacy)
  56. ML-KEM (Kyber)
  57. mTLS (Mutual TLS)
  58. NIST P-256 (secp256r1)
  59. NIST P-384 and P-521
  60. Nonce
  61. OCSP (Online Certificate Status Protocol)
  62. OCSP Stapling
  63. Padding (PKCS#7)
  64. PBKDF2
  65. Perfect Forward Secrecy (PFS)
  66. PKI (Public Key Infrastructure)
  67. Post-Quantum Cryptography (PQC)
  68. Root CA
  69. RSA
  70. RSA-OAEP
  71. RSA-PSS
  72. Salt
  73. SAN (Subject Alternative Name)
  74. scrypt
  75. Session Resumption
  76. SHA-1 (legacy)
  77. SHA-256
  78. SHA-3
  79. SNI (Server Name Indication)
  80. Stream Cipher
  81. TLS 1.2
  82. TLS 1.3
  83. TLS Handshake
  84. X.509 Certificate
  85. XKS (External Key Store)

Envelope Encryption Flow (Visual Reference)

Envelope Encryption Flow with AWS KMS
Envelope Encryption Flow with AWS KMS

The flow above visualizes the relationship between the terms Envelope Encryption, DEK, KEK, KMS, and AES-GCM. The application calls GenerateDataKey on AWS KMS, KMS returns both a plaintext DEK and the KEK-wrapped (encrypted) DEK, the application uses the plaintext DEK to encrypt the data locally with AES-256-GCM, and finally the ciphertext is persisted alongside the encrypted DEK before the plaintext DEK is wiped from memory. The KEK never leaves AWS KMS — that is the central property that makes envelope encryption a key-custody pattern rather than just a performance optimization.

A. Symmetric Encryption

AES (Advanced Encryption Standard)

AES is a symmetric block cipher standardized in 2001 as FIPS 197, operating on 128-bit blocks with 128-, 192-, or 256-bit keys. AES is the most widely deployed symmetric primitive in modern systems and is hardware-accelerated on essentially all contemporary x86_64 and ARMv8 CPUs through dedicated instructions (AES-NI on Intel/AMD, the ARMv8 Cryptography Extensions on ARM).
Related: AES-128 · AES-192 · AES-256 · Block Cipher · GCM Mode · ChaCha20-Poly1305
Source: FIPS 197 (AES) — NIST

AES-128

AES-128 is the AES variant with a 128-bit key and 10 rounds. It offers approximately 128 bits of classical security and is the typical choice when constant-time and bandwidth-sensitive workloads need a strong-but-fast cipher; it is also the default key size that TLS 1.3 selects with the cipher suite TLS_AES_128_GCM_SHA256.
Related: AES · AES-192 · AES-256 · GCM Mode
Source: FIPS 197 (AES) — NIST

AES-192

AES-192 is the AES variant with a 192-bit key and 12 rounds. It is rare in practice because AES-128 is fast enough for everyday workloads and AES-256 is the typical step-up choice when a higher security margin is required; AES-192 mostly survives in legacy specifications.
Related: AES · AES-128 · AES-256
Source: FIPS 197 (AES) — NIST

AES-256

AES-256 is the AES variant with a 256-bit key and 14 rounds. It is the default symmetric cipher for high-assurance workloads, for envelope encryption with AWS KMS data keys, and for any deployment that must satisfy the CNSA suite or maintain a strong margin against future cryptanalytic improvement.
Related: AES · AES-128 · GCM Mode · DEK · Envelope Encryption
Source: FIPS 197 (AES) — NIST

Block Cipher

A Block Cipher is a symmetric algorithm that transforms fixed-size plaintext blocks (e.g., 128 bits for AES) into ciphertext blocks under a secret key. Block ciphers are turned into secure encryption schemes by combining them with a mode of operation; on their own (i.e., ECB) they leak structure and are unsafe for general use.
Related: AES · Stream Cipher · CBC Mode · CTR Mode · GCM Mode
Source: NIST SP 800-38A — Block Cipher Modes

Stream Cipher

A Stream Cipher produces a keystream that is XOR'd with the plaintext one bit or byte at a time. ChaCha20 is the modern, vetted stream cipher in wide deployment (TLS, WireGuard), and CTR-mode AES is itself a stream-cipher construction built from a block cipher.
Related: ChaCha20-Poly1305 · CTR Mode · Block Cipher · Nonce
Source: Stream Cipher — NIST Glossary

ECB Mode

ECB (Electronic Codebook) encrypts each plaintext block independently with the same key. Identical plaintext blocks always produce identical ciphertext blocks, leaking block-level structure (the famous "ECB penguin" image is the canonical demonstration), so ECB is unsafe for general-purpose encryption.
Related: CBC Mode · CTR Mode · GCM Mode · Block Cipher
Source: NIST SP 800-38A — Block Cipher Modes

CBC Mode

CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block before encrypting; the first block is XOR'd with a random IV. CBC requires a unique random IV per message, requires padding to the block size, and provides no integrity by itself — without a separate MAC it is vulnerable to padding-oracle attacks.
Related: IV (Initialization Vector) · Padding (PKCS#7) · HMAC · GCM Mode · Block Cipher
Source: NIST SP 800-38A — Block Cipher Modes

CTR Mode

CTR (Counter) mode turns a block cipher into a stream cipher by encrypting an incrementing counter and XOR'ing the resulting keystream with the plaintext. CTR requires a unique nonce per (key, message) pair, has no padding requirement, and parallelizes well; it provides no integrity by itself.
Related: GCM Mode · Nonce · Stream Cipher · Block Cipher
Source: NIST SP 800-38A — Block Cipher Modes

GCM Mode

GCM (Galois/Counter Mode) combines CTR-mode encryption with a GHASH-based authentication tag to produce an AEAD scheme defined in NIST SP 800-38D. AES-GCM is the workhorse construction for TLS 1.3, IPsec, and AWS KMS-encrypted data; nonce reuse under the same key is catastrophic — it leaks the authentication subkey and breaks both confidentiality and integrity.
Related: AEAD · CTR Mode · Nonce · Authentication Tag · ChaCha20-Poly1305
Source: NIST SP 800-38D — GCM and GMAC

CCM Mode

CCM (Counter with CBC-MAC) is an AEAD mode defined in NIST SP 800-38C that combines CTR encryption with a CBC-MAC authentication tag. CCM is common in constrained environments such as Wi-Fi WPA2 (CCMP), Bluetooth, and Zigbee, and is the AEAD of choice when GCM's GHASH is too expensive in hardware.
Related: AEAD · GCM Mode · CTR Mode · CMAC
Source: NIST SP 800-38C — CCM Mode

ChaCha20-Poly1305

ChaCha20-Poly1305 is an AEAD construction defined in RFC 8439 that pairs the ChaCha20 stream cipher with the Poly1305 one-time MAC. It is the standard alternative to AES-GCM on platforms without AES hardware acceleration (older mobile and embedded CPUs), and it is widely used in TLS 1.3, WireGuard, and SSH.
Related: AEAD · Stream Cipher · GCM Mode · Nonce · TLS 1.3
Source: RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols

B. Asymmetric and Public-Key Cryptography

RSA

RSA is an asymmetric algorithm whose security rests on the hardness of factoring large integers. It supports both encryption (use RSA-OAEP) and signing (use RSA-PSS), with 3072-bit keys recommended for new deployments; the older 2048-bit RSA is still common but is approaching the lower bound of what is acceptable past 2030.
Related: RSA-PSS · RSA-OAEP · ECDSA · Ed25519
Source: RFC 8017 — PKCS#1 v2.2 (RSA)

RSA-PSS

RSA-PSS is the recommended RSA signature scheme defined in PKCS#1 v2.2 (RFC 8017). It uses a probabilistic padding (PSS) with a hash and a mask-generation function, and it is preferred over the older PKCS#1 v1.5 signature scheme because PSS has a tight security reduction to the RSA problem.
Related: RSA · RSA-OAEP · SHA-256
Source: RFC 8017 Section 8.1 — RSA-PSS

RSA-OAEP

RSA-OAEP is the recommended RSA encryption scheme defined in PKCS#1 v2.2 (RFC 8017). It uses the Optimal Asymmetric Encryption Padding to defend against chosen-ciphertext attacks (Bleichenbacher 1998) that broke the older PKCS#1 v1.5 encryption scheme.
Related: RSA · RSA-PSS · AES · Envelope Encryption
Source: RFC 8017 Section 7.1 — RSA-OAEP

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic-curve analog of DSA defined in FIPS 186-5. Signatures consist of an (r, s) pair, and security depends critically on a uniformly random per-signature nonce; biased or repeated nonces leak the private key (this is what compromised the Sony PS3 in 2010).
Related: EdDSA · Ed25519 · NIST P-256 (secp256r1) · RSA-PSS
Source: FIPS 186-5 — Digital Signature Standard (DSS)

EdDSA

EdDSA (Edwards-curve Digital Signature Algorithm) is a deterministic signature scheme defined in RFC 8032. It removes the per-signature random nonce requirement that has historically caused ECDSA failures, by deriving the nonce deterministically from the private key and the message.
Related: Ed25519 · ECDSA · Curve25519
Source: RFC 8032 — EdDSA Signature Schemes

Ed25519

Ed25519 is the EdDSA instantiation over the twisted Edwards form of Curve25519. It produces 64-byte signatures, is fast in software, has small (32-byte) public keys, and is the recommended default for new public-key signing deployments when interoperability allows it.
Related: EdDSA · Curve25519 · ECDSA · RSA
Source: RFC 8032 — EdDSA Signature Schemes

ECDH (Elliptic Curve Diffie-Hellman)

ECDH is the elliptic-curve form of Diffie-Hellman key agreement. An ephemeral variant (ECDHE, where the private key is freshly generated per session) provides forward secrecy and is the key-exchange backbone of TLS 1.2 (when configured with an ECDHE cipher suite) and of every TLS 1.3 handshake.
Related: Diffie-Hellman (Classical) · Curve25519 · NIST P-256 (secp256r1) · Forward Secrecy · TLS 1.3
Source: NIST SP 800-56A Rev. 3 — Pair-Wise Key Establishment

Diffie-Hellman (Classical)

Classical (finite-field) Diffie-Hellman is the 1976 public-key key-agreement protocol that allows two parties to derive a shared secret over an insecure channel. It has been superseded for most new deployments by ECDH on the standardized curves listed in NIST SP 800-186; classical DH still appears in older TLS 1.2 configurations and IPsec.
Related: ECDH · Forward Secrecy · TLS 1.2
Source: RFC 2631 — Diffie-Hellman Key Agreement Method

Curve25519

Curve25519 is a Montgomery elliptic curve designed by Daniel J. Bernstein for high-speed constant-time ECDH (the variant is called X25519). It is defined in RFC 7748 and is widely used in TLS, SSH, Signal, WireGuard, and Apple/iCloud key exchange; its companion signature curve is Ed25519.
Related: ECDH · Ed25519 · NIST P-256 (secp256r1)
Source: RFC 7748 — Elliptic Curves for Security

NIST P-256 (secp256r1)

P-256 (also known as secp256r1 or prime256v1) is the NIST elliptic curve with a 256-bit prime field. It is the most widely supported curve for ECDSA and ECDH across TLS certificates, hardware tokens, smart cards, AWS KMS, and the CA/Browser Forum trust stores; the parameters are specified in NIST SP 800-186.
Related: ECDSA · ECDH · Curve25519 · NIST P-384 / P-521
Source: NIST SP 800-186 — Recommendations for Discrete Logarithm-based Cryptography

NIST P-384 and P-521

P-384 and P-521 are the NIST elliptic curves with 384-bit and 521-bit prime fields, defined in SP 800-186. They are used when CNSA-suite or higher classical security levels (192-bit and 256-bit, respectively) are required — for example, in U.S. federal Top Secret systems and in CNSA 2.0-aligned commercial deployments.
Related: NIST P-256 (secp256r1) · ECDSA · ECDH
Source: NIST SP 800-186 — Recommendations for Discrete Logarithm-based Cryptography

C. Hash Functions and MACs

Cryptographic Hash Function

A Cryptographic Hash Function maps an arbitrary-length input to a fixed-length digest in a way that is collision-resistant, preimage-resistant, and second-preimage-resistant. SHA-256, SHA-3, and BLAKE3 are the current general-purpose choices; MD5 and SHA-1 are broken for collision resistance and must not be used in new designs.
Related: SHA-256 · SHA-3 · BLAKE3 · HMAC
Source: Hash Functions — NIST Computer Security Resource Center

SHA-256

SHA-256 is a 256-bit hash function from the SHA-2 family standardized in FIPS 180-4. It is the default cryptographic hash in TLS handshake transcripts, code signing, container image digests, certificate fingerprints, AWS Signature Version 4, and JWT (HS256/RS256/ES256).
Related: Cryptographic Hash Function · SHA-3 · HMAC · SHA-1 (legacy)
Source: FIPS 180-4 — Secure Hash Standard

SHA-3

SHA-3 is a hash function family based on the Keccak sponge construction and standardized in FIPS 202. It is a structurally independent alternative to SHA-2 with comparable security margins; the family also includes the extendable-output functions SHAKE128 and SHAKE256.
Related: SHA-256 · Cryptographic Hash Function · BLAKE3
Source: FIPS 202 — SHA-3 Standard

BLAKE3

BLAKE3 is a 2020 cryptographic hash function that produces 256-bit (or extendable) output. It is significantly faster than SHA-256 in software while preserving security, and supports parallel hashing and streaming output; it is widely used in content-addressable storage and integrity-check tooling.
Related: SHA-256 · SHA-3 · Cryptographic Hash Function
Source: The BLAKE3 Specification (BLAKE3 Team)

MD5 (legacy)

MD5 is a 128-bit hash function from 1992 (RFC 1321) that is broken for collision resistance. It must not be used for digital signatures or certificate fingerprints; it survives only in non-security legacy contexts such as ETag generation, S3 ContentMD5 checksums, and de-duplication.
Related: SHA-1 (legacy) · SHA-256 · Cryptographic Hash Function
Source: RFC 1321 — The MD5 Message-Digest Algorithm

SHA-1 (legacy)

SHA-1 is a 160-bit hash function from 1995 that is collision-broken: the SHAttered attack (Google & CWI, 2017) produced an explicit collision, and the cost of finding new collisions has continued to drop. SHA-1 is deprecated for digital signatures and TLS certificates and should not be used in new designs.
Related: MD5 (legacy) · SHA-256 · Cryptographic Hash Function
Source: FIPS 180-4 — Secure Hash Standard

HMAC

HMAC (Hash-based Message Authentication Code) defined in RFC 2104 constructs a keyed MAC from any cryptographic hash. HMAC-SHA-256 is the default integrity primitive across TLS, JWT (HS256), AWS Signature Version 4, and dozens of other protocols; it is also the building block of HKDF.
Related: Cryptographic Hash Function · SHA-256 · HKDF · CMAC · GMAC
Source: RFC 2104 — HMAC: Keyed-Hashing for Message Authentication

CMAC

CMAC (Cipher-based MAC) is a MAC built from a block cipher and defined in NIST SP 800-38B. AES-CMAC is the most common instantiation and is used in CCM, in IPsec's IKEv2, and in some constrained-environment protocols where hardware AES is available but a hash is not.
Related: HMAC · GMAC · AES · CCM Mode
Source: NIST SP 800-38B — CMAC Mode for Authentication

GMAC

GMAC is the authentication-only variant of AES-GCM defined in NIST SP 800-38D. It is used when integrity (but not confidentiality) is needed but the data is already in plaintext — for example, integrity-only IPsec ESP.
Related: GCM Mode · HMAC · CMAC · Authentication Tag
Source: NIST SP 800-38D — GCM and GMAC

D. Key Derivation and Password Hashing

HKDF

HKDF (HMAC-based Key Derivation Function) defined in RFC 5869 derives one or more cryptographically strong keys from input keying material via an Extract-then-Expand construction. TLS 1.3 uses HKDF throughout its key schedule, and HKDF is the standard answer for "I have a shared secret — how do I derive separate keys for encryption, MAC, and IV generation?"
Related: HMAC · SHA-256 · TLS 1.3 · HKDF-Expand-Label · PBKDF2
Source: RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

HKDF-Expand-Label

HKDF-Expand-Label is the labelled Expand wrapper that TLS 1.3 layers on top of HKDF (RFC 8446 Section 7.1). Every secret in the TLS 1.3 key schedule — handshake traffic secrets, application traffic secrets, exporter secrets, resumption master secret — is produced by Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length), where the label provides domain separation so that the same parent secret never produces colliding child keys for different roles.
Related: HKDF · HMAC · TLS 1.3 · TLS Handshake
Source: RFC 8446 Section 7.1 — Key Schedule

PBKDF2

PBKDF2 (Password-Based Key Derivation Function 2) defined in RFC 8018 / PKCS#5 derives a key from a password using a salt and an iteration count. It is acceptable as a password hash and is required by some compliance regimes, but it is weaker than Argon2 or scrypt against GPU attacks because it is not memory-hard.
Related: Argon2 · scrypt · bcrypt · HKDF · Salt
Source: RFC 8018 — PKCS#5: Password-Based Cryptography Specification v2.1

scrypt

scrypt defined in RFC 7914 is a memory-hard password-based KDF. The memory cost parameter makes large-scale GPU and ASIC attacks economically unattractive; scrypt is widely used in cryptocurrency wallets and as a password hash where Argon2 is not yet available.
Related: Argon2 · bcrypt · PBKDF2 · Salt
Source: RFC 7914 — The scrypt Password-Based Key Derivation Function

Argon2

Argon2 defined in RFC 9106 is the 2015 Password Hashing Competition winner. The recommended variant Argon2id is the default for new password hashing deployments; it offers tunable memory cost, time cost, and parallelism, and resists both GPU and side-channel attacks.
Related: scrypt · bcrypt · PBKDF2 · Salt
Source: RFC 9106 — Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work

bcrypt

bcrypt is a 1999 password hashing function by Provos and Mazières based on a modified Blowfish. It remains acceptable for legacy systems and has a long deployment history, but it is not memory-hard and is generally inferior to Argon2id and scrypt; bcrypt also caps inputs at 72 bytes.
Related: Argon2 · scrypt · PBKDF2 · Salt
Source: A Future-Adaptable Password Scheme — Provos & Mazières, USENIX 1999

E. AEAD and Mode Primitives

AEAD (Authenticated Encryption with Associated Data)

AEAD defined in RFC 5116 is a class of encryption schemes that simultaneously provide confidentiality for the plaintext and integrity for both the plaintext and an unencrypted associated-data field. AES-GCM and ChaCha20-Poly1305 are the standard AEADs; AEAD turns the historically error-prone task of combining a cipher and a MAC into a single primitive whose interface makes nonce misuse the only remaining footgun.
Related: GCM Mode · ChaCha20-Poly1305 · CCM Mode · Encrypt-then-MAC · Authentication Tag · Nonce
Source: RFC 5116 — An Interface and Algorithms for Authenticated Encryption

Encrypt-then-MAC

Encrypt-then-MAC is the generic-composition pattern in which the ciphertext is computed first and the MAC is then computed over that ciphertext. Bellare and Namprempre (2000) proved it is the only one of the three classical compositions — Encrypt-then-MAC, MAC-then-Encrypt, Encrypt-and-MAC — that achieves IND-CCA security for all secure cipher/MAC choices; this is why AEAD constructions internalise Encrypt-then-MAC and why TLS 1.0/1.1 MAC-then-Encrypt suites enabled the Lucky 13 padding-oracle attack.
Related: AEAD · HMAC · GCM Mode · CBC Mode
Source: Bellare & Namprempre — Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm (2000)

CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)

A CSPRNG is a deterministic random-bit generator whose output is computationally indistinguishable from uniformly random bits even to an attacker who sees prior output; it is the upstream primitive that produces nonces, IVs, salts, ephemeral keys, and DEKs. Operating systems expose CSPRNGs through getrandom(2) and /dev/urandom on Linux, arc4random_buf on BSD/macOS, and BCryptGenRandom on Windows; application code should use secrets (Python), crypto.randomBytes (Node.js), crypto/rand (Go), or equivalent — never math.random. Standardised DRBG constructions (AES-CTR-DRBG, HMAC-DRBG, Hash-DRBG) are specified in NIST SP 800-90A.
Related: Nonce · IV (Initialization Vector) · Salt · Key Rotation
Source: NIST SP 800-90A Rev. 1 — Recommendation for Random Number Generation Using Deterministic Random Bit Generators

Nonce

A Nonce (number used once) is a value that must be unique under a given key for each invocation of an encryption or signing operation. AES-GCM nonce reuse catastrophically breaks both confidentiality and authenticity; for high-throughput services the standard pattern is a 96-bit nonce composed of a 32-bit fixed prefix plus a 64-bit counter.
Related: IV (Initialization Vector) · GCM Mode · ChaCha20-Poly1305 · AEAD
Source: Nonce — NIST Glossary

IV (Initialization Vector)

An IV is a per-message input that randomizes encryption so two encryptions of the same plaintext produce different ciphertexts. IV requirements differ by mode: random for CBC, unique (not necessarily random) for CTR and GCM; in AEADs the IV is usually called the nonce.
Related: Nonce · CBC Mode · CTR Mode · GCM Mode
Source: NIST SP 800-38A — Block Cipher Modes

Salt

A Salt is a per-record random value added to a password or low-entropy input before hashing or key derivation. It defeats precomputed rainbow tables and makes brute force per-record rather than global; password-hashing libraries (Argon2id, scrypt, bcrypt) handle salt generation and storage for you.
Related: Argon2 · scrypt · PBKDF2 · bcrypt
Source: Salt — NIST Glossary

Authentication Tag

The Authentication Tag is the integrity output of an AEAD or MAC scheme (typically 16 bytes for AES-GCM and ChaCha20-Poly1305). Decryption must verify the tag in constant time before returning any plaintext; an AEAD library that returns plaintext on tag failure is unsafe to use.
Related: AEAD · GCM Mode · Constant-Time Comparison · HMAC
Source: NIST SP 800-38D — GCM and GMAC

Padding (PKCS#7)

PKCS#7 padding is the standard padding scheme for block-cipher modes that require full blocks (e.g., CBC). Each padding byte equals the number of padding bytes appended; a one-byte short message gets 15 bytes of 0x0F, a full-block message gets 16 bytes of 0x10.
Related: CBC Mode · Block Cipher · Authentication Tag
Source: RFC 5652 Section 6.3 — Content-Encryption Process (PKCS#7 padding)

Constant-Time Comparison

Constant-Time Comparison is a byte-comparison that always inspects every byte and never short-circuits on the first mismatch. Using a normal == or memcmp on MAC tags is a timing side-channel bug; every cryptography library exposes a constant-time equal primitive (e.g., hmac.compare_digest in Python, subtle.ConstantTimeCompare in Go).
Related: Authentication Tag · HMAC · AEAD
Source: Side-Channel Attack — NIST Glossary

F. Forward Secrecy and Post-Quantum

Forward Secrecy (FS)

Forward Secrecy is the property that compromise of a long-term private key does not allow decryption of past sessions. It is achieved by deriving each session's keys from an ephemeral key-agreement exchange (typically ECDHE) instead of from the long-term key directly.
Related: Perfect Forward Secrecy · ECDH · TLS 1.3 · TLS 1.2
Source: RFC 8446 Section 1.2 — Major Differences from TLS 1.2

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy is forward secrecy where every session uses a fresh ephemeral key pair. TLS 1.3 mandates PFS by removing all non-ephemeral key-exchange modes; in TLS 1.2 PFS is achieved only when an ECDHE or DHE cipher suite is negotiated (not a plain RSA suite).
Related: Forward Secrecy · TLS 1.3 · ECDH
Source: RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3

Post-Quantum Cryptography (PQC)

Post-Quantum Cryptography is the class of algorithms believed to remain secure against a sufficiently large quantum computer (which would break RSA and elliptic-curve cryptography via Shor's algorithm). NIST has standardized ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for signatures, and SLH-DSA (FIPS 205) as a hash-based signature backup.
Related: ML-KEM (Kyber) · TLS 1.3 · RSA · ECDSA
Source: Post-Quantum Cryptography — NIST CSRC

ML-KEM (Kyber)

ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) standardized in FIPS 203 is the post-quantum replacement for elliptic-curve key exchange; it is the algorithm previously known as Kyber. Modern TLS deployments adopt it as a hybrid with X25519 (typically X25519MLKEM768) so that today's traffic is protected against future "harvest-now, decrypt-later" attacks.
Related: Post-Quantum Cryptography · ECDH · Curve25519 · TLS 1.3
Source: FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard

G. Key Management and Envelope Encryption

For a deep dive on how AWS KMS evolved into the service that backs the envelope-encryption pattern below, see AWS History and Timeline regarding AWS Key Management Service.

Envelope Encryption

Envelope Encryption is the pattern of encrypting data with a Data Encryption Key (DEK) and then encrypting (wrapping) the DEK with a Key Encryption Key (KEK). On AWS KMS the KEK never leaves the service: the application calls GenerateDataKey, receives both the plaintext DEK and the KEK-wrapped DEK, encrypts data locally with AES-256-GCM, persists the ciphertext alongside the encrypted DEK, and discards the plaintext DEK. The pattern scales because the per-byte work is done locally, not at KMS.
Related: DEK · KEK · KMS · AWS KMS Customer Managed Key · AWS KMS Encryption Context · Key Wrap (RFC 3394)
Source: Envelope encryption — AWS KMS Developer Guide

DEK (Data Encryption Key)

A DEK is the symmetric key (typically AES-256) used to encrypt application data. In envelope encryption the DEK is generated per object (or per session), used once, and discarded after the encrypted DEK is persisted; this makes "data key rotation" effectively free because every new write uses a fresh DEK anyway.
Related: KEK · Envelope Encryption · AES-256 · GCM Mode
Source: Data keys — AWS KMS Developer Guide

KEK (Key Encryption Key)

A KEK is a key whose only purpose is to encrypt (wrap) other keys. In AWS KMS the KMS key plays the KEK role; DEK rotation is decoupled from KEK rotation, and a long-lived KEK can wrap many short-lived DEKs without ever appearing in plaintext outside the HSM.
Related: DEK · Envelope Encryption · Key Wrap (RFC 3394) · AWS KMS Customer Managed Key · HSM
Source: NIST SP 800-57 Part 1 Rev. 5 — Key Management Recommendations

KMS (Key Management Service)

A KMS is a managed service that generates, stores, and operates on cryptographic keys behind an API while keeping the key material inside HSMs. AWS KMS, Google Cloud KMS, and Azure Key Vault are the three major cloud KMS offerings; all expose roughly the same surface (Encrypt/Decrypt, GenerateDataKey, Sign/Verify, key policies, audit logs).
Related: AWS KMS Customer Managed Key · AWS CloudHSM · Envelope Encryption · HSM · FIPS 140-2 and FIPS 140-3
Source: What is AWS Key Management Service? — AWS Docs

AWS KMS Customer Managed Key

A customer managed key is an AWS KMS key whose policy, rotation, alias, deletion window, and lifecycle the customer controls. AWS originally called these keys "Customer Master Keys (CMKs)" and retired that terminology in mid-2021; today AWS KMS keys are categorized as customer managed, AWS managed, or AWS owned, and the legacy "CMK" abbreviation should be avoided in new documentation. Customer managed keys are the recommended choice over AWS managed keys when you need explicit key policies, cross-account grants, auditable rotation cadence, or imported key material.
Related: KMS · AWS KMS Multi-Region Key · Key Rotation · AWS KMS Encryption Context
Source: AWS KMS keys — AWS KMS Developer Guide

AWS KMS Multi-Region Key

A Multi-Region Key is an AWS KMS key that exists as a primary key in one Region and replicas in other Regions, sharing the same key ID and key material. It enables cross-Region decryption of envelope-encrypted data without round-tripping through one Region — an object encrypted in us-east-1 can be decrypted directly in ap-northeast-1 if the multi-region key has a replica there.
Related: AWS KMS Customer Managed Key · Envelope Encryption · KMS
Source: Multi-Region keys in AWS KMS — AWS Docs

BYOK (Bring Your Own Key)

BYOK (Bring Your Own Key) is the pattern of importing customer-generated key material into a managed KMS so that the cryptographic operations stay inside the cloud HSM while the originating entropy is provably the customer's. With AWS KMS, the customer creates a customer managed key with no key material, calls GetParametersForImport to receive a per-import RSA wrapping public key, wraps the plaintext key material with the chosen wrapping algorithm (RSAES_OAEP_SHA_256 directly for 256-bit symmetric material, or RSA_AES_KEY_WRAP_SHA_256 which adds an AES-KW step per RFC 3394 / 5649 for asymmetric or otherwise oversized material), and calls ImportKeyMaterial. The trade-off is that automatic rotation is disabled for keys with imported material, so the customer must script the re-import cadence.
Related: AWS KMS Customer Managed Key · Key Wrap (RFC 3394) · KEK · XKS (External Key Store) · RSA-OAEP
Source: Importing key material into AWS KMS keys — AWS Docs

XKS (External Key Store)

An External Key Store (XKS) is an AWS KMS configuration in which all cryptographic operations of an AWS KMS key are proxied to an external HSM that the customer operates outside AWS, via an HTTPS-reachable XKS proxy that implements the XKS proxy API. The key material never resides in AWS, and AWS KMS functions as the audit, policy, and protocol layer; XKS is the right answer when regulation requires key material to remain on customer-controlled hardware while AWS-integrated services (S3 SSE-KMS, EBS, RDS) still need a KMS-shaped interface. The trade-off is added operational burden and latency, plus an availability dependency on the external HSM and proxy.
Related: BYOK · AWS CloudHSM · AWS KMS Customer Managed Key · HSM
Source: External key stores — AWS KMS Developer Guide

HSM (Hardware Security Module)

An HSM is a tamper-resistant hardware device that generates and operates on keys without exposing the key material on a general-purpose CPU. FIPS 140-validated HSMs back AWS KMS, AWS CloudHSM, Google Cloud HSM, Azure Dedicated HSM, and most certificate authorities; consumer-grade variants include YubiHSM and TPM 2.0.
Related: AWS CloudHSM · FIPS 140-2 and FIPS 140-3 · KMS · Root CA
Source: Hardware Security Module — NIST Glossary

AWS CloudHSM

AWS CloudHSM is a managed single-tenant HSM cluster (FIPS 140-3 Level 3 validated on the current hsm2m.medium; the legacy hsm1.medium was FIPS 140-2 Level 3) that customers operate directly via PKCS#11, JCE, or KSP. It is the right choice when single-tenant key isolation is a hard compliance requirement that AWS KMS's multi-tenant HSM pool cannot satisfy, at the cost of more operational burden.
Related: HSM · KMS · FIPS 140-2 and FIPS 140-3
Source: What is AWS CloudHSM? — AWS Docs

FIPS 140-2 and FIPS 140-3

FIPS 140-2 and FIPS 140-3 are the NIST cryptographic-module validation standards. Modules are validated at Levels 1–4 under the Cryptographic Module Validation Program (CMVP); FIPS 140-3 is the current standard (FIPS 140-2 stopped accepting new validations in 2021), and U.S. federal procurement frequently requires FIPS 140-2 Level 3 or higher for key-handling hardware.
Related: HSM · AWS CloudHSM · KMS
Source: Cryptographic Module Validation Program (CMVP) — NIST

Key Rotation

Key Rotation is the periodic replacement of an active key with a new key while preserving the ability to decrypt previously encrypted data. AWS KMS supports automatic rotation of symmetric KEKs — annually by default for AWS managed keys, and opt-in for customer managed keys with a configurable rotation period of 90 to 2,560 days — with no application change required, because the encrypted DEKs continue to reference the previous KEK material via the KMS key's internal key-material versions.
Related: KEK · AWS KMS Customer Managed Key · Envelope Encryption · KMS
Source: Rotating AWS KMS keys — AWS Docs

Key Wrap (RFC 3394)

Key Wrap defined in RFC 3394 (AES Key Wrap, AES-KW) and its RFC 5649 extension is a deterministic AES-based mechanism for encrypting (wrapping) one symmetric key with another. AWS KMS uses RFC 3394 / 5649 internally for wrapping data keys, and key-import workflows (BYOK) commonly require wrapping the imported key material with AES-KW under a KMS-provided wrapping key.
Related: KEK · Envelope Encryption · AES-256
Source: RFC 3394 — Advanced Encryption Standard (AES) Key Wrap Algorithm

AWS KMS Encryption Context

Encryption Context is an AWS KMS key-value map that is cryptographically bound to a ciphertext via the AEAD additional-authenticated-data (AAD) field. It is the standard mechanism to bind a ciphertext to its operational context (tenant ID, object owner, request purpose): every Decrypt call must present the same context the Encrypt used, the same key-value pairs can be referenced from IAM and key-policy condition keys to constrain which principals may decrypt with which contexts, and every Encrypt and Decrypt is auditable via CloudTrail with the context included.
Related: Envelope Encryption · AEAD · AWS KMS Customer Managed Key
Source: Encryption context — AWS KMS Developer Guide

H. PKI and Certificates

For practical certificate inspection that uses several of the terms below, see the SSL/TLS Certificate Decoder Tool on this site — it parses a PEM/DER certificate locally in the browser and lays out the SAN, chain, signature, and validity fields side by side.

PKI (Public Key Infrastructure)

PKI is the set of policies, processes, hardware, and software that issue, distribute, validate, and revoke X.509 certificates. The "Internet PKI" used by HTTPS is profiled in RFC 5280 and operated by public CAs under the CA/Browser Forum Baseline Requirements; AWS Certificate Manager (ACM) and AWS Private CA are AWS's managed surfaces on top of this PKI.
Related: X.509 Certificate · CA (Certificate Authority) · Root CA · Intermediate CA · Certificate Chain
Source: RFC 5280 — Internet X.509 PKI Certificate and CRL Profile

X.509 Certificate

X.509 is the ITU-T standard certificate format profiled for the Internet in RFC 5280. An X.509 certificate binds a public key to a subject (with names carried in the SAN extension) and is signed by a CA; an end-entity certificate is the "leaf" served by a TLS endpoint or used for code signing.
Related: SAN (Subject Alternative Name) · CA · CSR · Certificate Chain · PKI
Source: RFC 5280 — Internet X.509 PKI Certificate and CRL Profile

CSR (Certificate Signing Request)

A CSR (PKCS#10, RFC 2986) is a signed request from the certificate subject to a CA, containing the public key and the identity attributes (Subject and SAN) the subject wants the CA to certify. The CSR is signed by the subject's private key, which proves the subject controls the key it is asking the CA to bind to.
Related: X.509 Certificate · CA · SAN
Source: RFC 2986 — PKCS#10 Certification Request Syntax Specification

CA (Certificate Authority)

A Certificate Authority is an entity that issues and signs X.509 certificates. Public CAs are trusted by browsers and operating systems by virtue of being in root trust stores managed under the CA/Browser Forum Baseline Requirements; private CAs are operated within an organization for internal mTLS, code signing, or device identity.
Related: Root CA · Intermediate CA · X.509 Certificate · PKI
Source: CA/Browser Forum Baseline Requirements

Root CA

A Root CA is a self-signed Certificate Authority whose certificate ships in browser and OS trust stores. Root keys are kept offline in HSMs and used only to sign Intermediate CAs, never end-entity certificates — this separation lets a compromise of an Intermediate be remediated by revoking that Intermediate without losing the root's trust-anchor status.
Related: CA · Intermediate CA · Certificate Chain · HSM
Source: CA/Browser Forum Baseline Requirements

Intermediate CA

An Intermediate CA is a CA whose certificate is signed by a Root CA (or another Intermediate). End-entity certificates are issued by Intermediates so that compromise of an Intermediate does not require rotating the trust-anchor root; TLS servers must present all required Intermediates in the handshake.
Related: Root CA · Certificate Chain · CA · X.509 Certificate
Source: RFC 5280 Section 3.2 — Certification Paths and Trust

Certificate Chain

A Certificate Chain is the ordered list from an end-entity certificate up through Intermediate CAs to a trusted Root CA. TLS servers must present the end-entity and all required Intermediates (but not the Root) in the handshake; the relying party validates each signature in the chain and checks each certificate against revocation status.
Related: X.509 Certificate · Root CA · Intermediate CA · OCSP · CRL
Source: RFC 5280 — Internet X.509 PKI Certificate and CRL Profile

SAN (Subject Alternative Name)

The Subject Alternative Name extension (RFC 5280 Section 4.2.1.6) carries the list of DNS names, IP addresses, email addresses, and other identifiers a certificate is valid for. Modern browsers ignore the legacy Common Name field and validate only SAN; a certificate without a SAN is unusable for a TLS server name match.
Related: X.509 Certificate · CSR · SNI
Source: RFC 5280 Section 4.2.1.6 — Subject Alternative Name

OCSP (Online Certificate Status Protocol)

OCSP defined in RFC 6960 lets a client ask a CA-operated responder whether a given certificate has been revoked. It replaces the bulk download model of CRLs with a per-certificate query; the privacy issue of leaking which sites you visit to the CA is solved by OCSP Stapling.
Related: OCSP Stapling · CRL · X.509 Certificate · CA
Source: RFC 6960 — X.509 Internet PKI: Online Certificate Status Protocol

OCSP Stapling

OCSP Stapling (RFC 6066 Section 8 "Certificate Status Request") lets the TLS server fetch and cache a fresh OCSP response for its certificate and attach it ("staple" it) to the handshake. This avoids privacy-leaking client-to-CA OCSP queries and reduces handshake latency; combined with the Must-Staple certificate extension (RFC 7633) it provides hard-fail revocation checking by instructing relying parties to refuse the connection if a stapled OCSP response is missing.
Related: OCSP · CRL · TLS Handshake
Source: RFC 6066 Section 8 — Certificate Status Request (OCSP Stapling)

CRL (Certificate Revocation List)

A CRL is a CA-signed list of revoked certificate serial numbers (RFC 5280). CRLs are bulk-downloaded by relying parties (or by intermediate revocation services like CRLSets and OneCRL) and remain the canonical fallback when OCSP is unavailable; private CAs commonly distribute CRLs over HTTP from a well-known URL.
Related: OCSP · X.509 Certificate · CA
Source: RFC 5280 Section 5 — CRL and CRL Extensions Profile

SNI (Server Name Indication)

SNI defined in RFC 6066 Section 3 lets a TLS client send the hostname it intends to reach in the ClientHello, enabling one IP address to serve multiple certificates. Cleartext SNI is the last meaningful information leak in a modern TLS connection; Encrypted ClientHello (ECH) is the IETF-standardized replacement that closes the leak.
Related: TLS Handshake · SAN · ALPN
Source: RFC 6066 Section 3 — Server Name Indication

I. TLS

TLS 1.2

TLS 1.2 defined in RFC 5246 (2008) is still widely supported but has known weaknesses: forward secrecy is not mandated (a plain RSA key-exchange suite has no FS), weak cipher suites have historically been negotiable, and the handshake takes two round trips. New deployments should prefer TLS 1.3.
Related: TLS 1.3 · Cipher Suite · TLS Handshake · Forward Secrecy
Source: RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2

TLS 1.3

TLS 1.3 defined in RFC 8446 (2018) mandates forward secrecy (every key exchange is ECDHE or DHE), removes all known-broken ciphers (CBC modes, RC4, MD5/SHA-1 signatures, static RSA key exchange), simplifies the handshake to one round trip, and adds 0-RTT for resumed connections.
Related: TLS 1.2 · TLS Handshake · Cipher Suite · Session Resumption · 0-RTT
Source: RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3

TLS Handshake

The TLS Handshake is the protocol exchange that authenticates the server (and optionally the client), agrees on a cipher suite and ECDHE group, and derives session keys via HKDF. In TLS 1.3 it completes in one round trip (ClientHello + ServerHello/Finished + Finished), and in TLS 1.2 it takes two round trips.
Related: TLS 1.3 · TLS 1.2 · Cipher Suite · HKDF · SNI
Source: RFC 8446 Section 4 — Handshake Protocol

Cipher Suite

A Cipher Suite is the bundle of algorithms negotiated in a TLS handshake. In TLS 1.3 the suite names only the AEAD and hash (e.g., TLS_AES_128_GCM_SHA256) because key exchange and signature algorithms are negotiated separately; the TLS 1.3 suite list is short and curated, with no exportable or otherwise weakened options.
Related: TLS 1.3 · TLS 1.2 · GCM Mode · ChaCha20-Poly1305
Source: RFC 8446 Appendix B.4 — Cipher Suites

Session Resumption

Session Resumption skips the full handshake on a follow-up connection by reusing a previously derived secret. TLS 1.3 implements it via Pre-Shared Keys (PSK) carried in NewSessionTicket messages, and TLS 1.2 implements it via session IDs or session tickets (RFC 5077).
Related: 0-RTT · TLS 1.3 · TLS Handshake
Source: RFC 8446 Section 2.2 — Resumption and PSK

0-RTT (Zero Round-Trip Time Data)

0-RTT is the TLS 1.3 mode that allows the client to send application data in its very first flight by using a PSK from a prior session. The trade-off is loss of forward secrecy for the 0-RTT data and risk of replay, so 0-RTT must be restricted to idempotent operations (typically only safe HTTP methods like GET) and is disabled by default in many TLS stacks.
Related: Session Resumption · TLS 1.3 · Forward Secrecy
Source: RFC 8446 Section 2.3 — 0-RTT Data

ALPN (Application-Layer Protocol Negotiation)

ALPN defined in RFC 7301 is the TLS extension that lets a client and server agree, inside the handshake, on which application-layer protocol to speak (e.g., h2, http/1.1, h3) before any application bytes flow. ALPN is what makes HTTP/2 and HTTP/3 negotiable on the same TLS endpoint as HTTP/1.1.
Related: TLS Handshake · SNI · TLS 1.3
Source: RFC 7301 — TLS Application-Layer Protocol Negotiation Extension

mTLS (Mutual TLS)

mTLS is TLS where both the server and the client present X.509 certificates; the server authenticates the client by validating the client certificate chain. mTLS is the standard transport-layer authentication mechanism for service-to-service communication (service mesh, internal APIs, ACM Private CA-issued client certs); OAuth 2.0 Mutual-TLS Client Authentication (RFC 8705) builds on top of it.
Related: TLS 1.3 · TLS Handshake · X.509 Certificate · Certificate Chain
Source: RFC 8446 Section 4.2.4 — Client Authentication (mTLS)

Cryptographic Best Practices for 2026+

The following is a decision sheet for new deployments, derived from the entries above. Each recommendation links back to its glossary entry so that the rationale can be re-read in context.

Recommended primitives by role

  • AEAD (bulk encryption): AES-256-GCM when AES-NI or ARMv8 Crypto Extensions are available; ChaCha20-Poly1305 on platforms without AES hardware acceleration. Always pair with a unique nonce per (key, message).
  • Public-key signing: Ed25519 as the default. Use ECDSA on P-256 when interoperability with HSMs, smart cards, AWS KMS, or CA/Browser Forum certificates is required. Use RSA-PSS with 3072-bit or larger keys only when legacy interop demands RSA.
  • Public-key encryption / key encapsulation: ECDH/ECDHE on X25519. Use RSA-OAEP only for legacy interoperability.
  • Hash: SHA-256 for general-purpose integrity and signatures; BLAKE3 when raw software speed matters; SHA-3 for NIST-style structural diversification.
  • Key derivation: HKDF (and HKDF-Expand-Label inside TLS 1.3-style key schedules) from a shared secret; Argon2id from a password.
  • Key agreement / KEX: ECDHE on X25519, layered with ML-KEM-768 as the hybrid post-quantum X25519MLKEM768 group for all new TLS endpoints.
  • Transport security: TLS 1.3 only, with PFS enforced by construction. Disable TLS 1.2 for greenfield services; if 1.2 must remain, allow only ECDHE+AEAD suites with SHA-256 or stronger.
  • Key custody: Envelope encryption with a customer managed key, encryption context bound as AEAD AAD, and an explicit rotation cadence.

Things never to do

  • Use ECB Mode for anything except a one-shot single-block primitive.
  • Reuse an AES-GCM nonce under the same key — this leaks the authentication subkey and breaks both confidentiality and authenticity.
  • Sign or verify with MD5 or SHA-1; rely on either as a security-bearing fingerprint.
  • Generate or accept RSA keys shorter than 2048 bits; 1024-bit RSA is broken at nation-state scale.
  • Roll a hand-built cipher, MAC, or KDF instead of using a vetted library that already exposes AEAD and HKDF.
  • Compare MAC tags or password hashes with == or memcmp; use constant-time comparison.
  • Use PKCS#1 v1.5 RSA encryption (Bleichenbacher 1998) or the PKCS#1 v1.5 signature scheme in new designs; prefer RSA-OAEP and RSA-PSS.
  • Negotiate static-RSA TLS key exchange — it has no forward secrecy and is removed from TLS 1.3 entirely.
  • Derive entropy from Math.random, rand(), the current timestamp, or any other non-CSPRNG source.

Migration Guidance

Cryptographic migrations are gradual: legacy systems live alongside modern ones during a planned phase-out window. The following five tracks are the migrations in progress as of 2026.
  • TLS 1.2 → TLS 1.3
    Status: TLS 1.3 is supported by every major server, browser, and client library since ~2020. Timeline: deprecate TLS 1.2 for greenfield workloads now; keep 1.2 enabled only where pinned IoT or embedded clients require it. Action: enable TLS 1.3 first in the negotiation order, disable CBC-mode 1.2 suites, monitor handshake failures for one release cycle, then drop 1.2.
  • SHA-1 → SHA-256
    Status: SHA-1 is collision-broken (SHAttered, 2017) and removed from CA/Browser-Forum public TLS certificates, browser code-signing roots, and most enterprise PKI. Timeline: SHA-1 in private CAs and legacy SSH host keys should already be retired. Action: re-issue any remaining SHA-1-signed certificates and HMAC-SHA-1 deployments to SHA-256; verify cipher suites and JWT signing algorithms.
  • PBKDF2 / bcrypt → Argon2id
    Status: Argon2id (RFC 9106) is the 2015 Password Hashing Competition winner and is exposed by every modern language ecosystem. Timeline: migrate on next user login (re-hash the supplied password with Argon2id and replace the stored hash) rather than running a one-shot batch. Action: keep a dual-verify path that recognises legacy PBKDF2 / bcrypt hashes until all active accounts have re-authenticated.
  • RSA → Ed25519 or ECDSA
    Status: Ed25519 has full library and hardware coverage; ECDSA on P-256 is the interop-safe alternative. Timeline: prefer Ed25519 for SSH host/user keys, code signing, and JWTs in new deployments; retain RSA-PSS only where a counterparty cannot accept ECC. Action: rotate SSH and code-signing keys at the next routine renewal, picking Ed25519 unless the verifier ecosystem forbids it.
  • Classical KEX → Hybrid Post-Quantum KEX
    Status: ML-KEM (FIPS 203, August 2024) is the standardised KEM and is shipping in TLS libraries as the X25519MLKEM768 hybrid group; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures are propagating more slowly because CA chains and code-signing infrastructure must adopt them. Timeline: enable hybrid PQC KEX now to defeat "harvest-now, decrypt-later" capture of long-lived secrets; track the CNSA 2.0 2027 / 2030 / 2033 milestones for the federal signature migration. Action: set X25519MLKEM768 first in the TLS supported-groups list, keep X25519 as a fallback, and revisit signing-algorithm choices once ML-DSA support is broad in CAs and TPMs.

Frequently Asked Questions

When should I pick AES-GCM versus ChaCha20-Poly1305?

On hardware with AES-NI or equivalent (essentially all modern x86_64 and ARMv8 CPUs), AES-GCM is the fastest and most widely supported AEAD. On platforms without AES hardware acceleration (older mobile and embedded CPUs), ChaCha20-Poly1305 is significantly faster than software AES and is constant-time by construction. TLS 1.3 negotiates between them and most stacks default to AES-GCM when hardware support is detected.

When should I use RSA versus ECDSA versus Ed25519?

For new public-key signing deployments, Ed25519 is the recommended default: it has small keys, small signatures, fast verification, and is deterministic (no per-signature nonce). Use ECDSA on P-256 when interoperability with hardware (smart cards, HSMs, TPMs, AWS KMS) or with CA/Browser-Forum certificates is required. Use RSA only when you must interoperate with systems that do not yet support elliptic-curve keys; prefer at least 3072-bit keys and RSA-PSS for signatures and RSA-OAEP for encryption.

Why is Envelope Encryption preferred over directly encrypting data with a KMS key?

AWS KMS Encrypt and Decrypt have a 4 KB plaintext limit and every call is a round trip to KMS. Envelope encryption generates a DEK with GenerateDataKey, returns both the plaintext DEK and the KEK-wrapped DEK, and lets the application encrypt arbitrary-size data locally with AES-256-GCM. The plaintext DEK is short-lived in memory and the encrypted DEK is stored alongside the ciphertext — giving you scalable encryption with KMS-grade key custody while the KEK remains inside KMS as covered in the glossary entry above.

Is TLS 1.2 still acceptable in 2026?

TLS 1.2 is still widely supported and not broken when configured correctly (forward-secrecy cipher suites only, no RSA key exchange, no CBC modes, no SHA-1 signatures). However, new deployments should prefer TLS 1.3 because it removes all known-broken primitives by construction, mandates forward secrecy, and reduces the handshake to one round trip. TLS 1.0 and 1.1 are formally deprecated by RFC 8996 and should be disabled.

Do I need to migrate to post-quantum cryptography now?

For new TLS deployments, enable hybrid post-quantum key exchange (typically X25519MLKEM768, combining X25519 with ML-KEM-768) as soon as your TLS library supports it — this protects today's traffic against harvest-now, decrypt-later attacks. For signing (TLS certificates, code signing, JWTs), the classical ECDSA / Ed25519 algorithms are still in use until ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) ship through CA chains; track the NIST migration timeline rather than rolling your own.

Related Articles on hidekazu-konishi.com


References


References:
Tech Blog with curated related content

Written by Hidekazu Konishi