Cryptography Vocabulary for Developers: Encryption, Key Management, and PKI Terms Explained

Cryptography vocabulary appears in security reviews, architecture discussions, vendor evaluations, and compliance audits. Using the wrong term — or using the right term imprecisely — signals to peers that you are working from a surface-level understanding. This guide covers the vocabulary you need to participate confidently in engineering conversations about encryption, key management, and transport security.

Symmetric vs Asymmetric Encryption

The most fundamental distinction in applied cryptography is between symmetric and asymmetric encryption algorithms, and it determines which tool is appropriate for a given problem.

Symmetric Encryption

Symmetric encryption uses the same key to encrypt and decrypt data. The current standard for symmetric encryption is AES-256-GCM. The name encodes the full specification:

AES — Advanced Encryption Standard, the underlying cipher
256 — key length in bits; longer keys increase resistance to brute-force attacks
GCM — Galois/Counter Mode, the mode of operation

GCM is an authenticated encryption mode: it produces both a ciphertext (the encrypted data) and an authentication tag (a short value that proves the ciphertext has not been tampered with). This is the critical distinction from older modes like CBC, which provide confidentiality but not integrity without a separate MAC.

Symmetric encryption is used for bulk data encryption — encrypting a database field, a file on disk, or a large body of data in transit — because it is fast.

Asymmetric Encryption

Asymmetric encryption uses a mathematically linked key pair: a public key encrypts data, and only the corresponding private key can decrypt it. The two dominant asymmetric algorithms are:

RSA — widely deployed, key sizes of 2048 or 4096 bits; computationally expensive
ECC (Elliptic Curve Cryptography) — provides equivalent security to RSA at significantly shorter key lengths; a 256-bit ECC key is considered equivalent to a 3072-bit RSA key, making it preferable for mobile devices and TLS

“We use AES-256-GCM for data at rest and RSA-2048 for key wrapping in our legacy services — we’re switching new services to ECDH key exchange to reduce handshake overhead.”

Envelope Encryption Pattern

Applying asymmetric encryption directly to large data is impractical — it is slow and the data size constraints are tight. The industry-standard solution is the envelope encryption pattern, used by every major cloud KMS (AWS, GCP, Azure).

How Envelope Encryption Works

A DEK (data encryption key) is generated — a random symmetric key used to encrypt the actual data with AES-256-GCM
The DEK itself is then encrypted (wrapped) using a KEK (key encryption key) stored in a KMS (Key Management Service)
The encrypted DEK is stored alongside the ciphertext; the plaintext DEK never persists

To decrypt, the application requests that the KMS unwrap the DEK using the KEK, decrypts the data, then discards the plaintext DEK from memory.

Why Envelope Encryption Matters

The pattern solves three problems at once:

Security: The master key (KEK) never leaves the KMS. The application only ever holds the DEK, and only transiently.
Rotation at scale: To rotate encryption, you re-encrypt only the DEK with a new KEK — not all the underlying data. On a multi-terabyte dataset, this is the difference between a 100ms operation and a multi-day migration.
Audit trail: Every DEK unwrap is logged in the KMS, giving a complete access audit trail without instrumenting the application.

“We use envelope encryption — each record gets its own DEK, the DEK is wrapped with our KMS key, and AWS KMS manages the full KEK lifecycle including automatic annual rotation.”

TLS 1.3 Handshake Vocabulary

TLS (Transport Layer Security) is the protocol that secures data in transit. Understanding its vocabulary is essential for any conversation about API security, certificate management, or network architecture.

TLS 1.3 vs TLS 1.2

TLS 1.3 (RFC 8446, 2018) is the current standard. The key differences from TLS 1.2:

Removes weak and legacy cipher suites (RC4, 3DES, RSA key exchange, SHA-1)
Reduces the handshake from 2-RTT (two round trips) to 1-RTT, with an optional 0-RTT resumption mode
Mandates perfect forward secrecy for all cipher suites

Key Certificate Chain Vocabulary

A TLS certificate is not a standalone file — it is part of a certificate chain:

Root CA — the Certificate Authority at the top of the chain; its certificate is pre-installed in operating systems and browsers
Intermediate CA — a CA whose certificate is signed by the root CA; intermediate CAs issue leaf certificates to insulate the root CA from day-to-day operations
Leaf certificate — the certificate presented by the server; signed by an intermediate CA

SNI (Server Name Indication) is a TLS extension that lets a client specify which hostname it is connecting to before the TLS handshake completes, enabling one IP address to host multiple TLS certificates.

OCSP stapling is a mechanism where the server proactively attaches a recent certificate validity response from the CA to the TLS handshake, eliminating the need for the client to make a separate OCSP request. Without stapling, certificate revocation checking adds latency and privacy exposure.

Perfect Forward Secrecy

Perfect forward secrecy (PFS) means that compromising a server’s long-term private key does not compromise past session traffic. It works by using ephemeral key pairs for each TLS session — key exchange uses ECDH (Elliptic Curve Diffie-Hellman) to derive a session key that is discarded after use. Even if an attacker recorded all past TLS traffic and later obtained the server’s private key, they cannot decrypt it.

“We enforce TLS 1.3 minimum on all external endpoints and require PFS cipher suites — ephemeral ECDH only. Certificate pinning is explicitly not used in the mobile client given the operational risk of pin rotation failures.”

Key Management Vocabulary

Key Rotation

Key rotation is the process of replacing a cryptographic key with a new one on a schedule or in response to a security event. Modern KMS systems support automated rotation — the KMS generates a new key version on a defined schedule (typically annually), and all new encryption operations use the latest version. Old key versions are retained for decryption of data encrypted before the rotation.

Rotation is triggered by schedule, suspected compromise, or significant personnel departure (an employee with key access leaving the organisation).

Key Derivation

Key derivation produces cryptographic keys from a source secret (typically a password). The two standard algorithms are:

PBKDF2 (Password-Based Key Derivation Function 2) — applies a pseudorandom function (typically HMAC-SHA256) many thousands of times; the high iteration count makes brute-force attacks expensive. A salt (random value unique to each user) prevents precomputed rainbow table attacks.
HKDF (HMAC-based Key Derivation Function) — used to derive multiple purpose-specific keys from a single high-entropy input (not suitable for passwords; use PBKDF2 for those)

HSM

An HSM (Hardware Security Module) is a dedicated hardware device for cryptographic key generation and storage. Core HSM guarantees:

Tamper resistance: physical attack attempts trigger automatic key destruction
Key material isolation: private keys and KEKs are generated inside the HSM and never exported in plaintext
Common HSM use cases: signing root and intermediate CA certificates, storing the KEK for an enterprise KMS, meeting regulatory requirements

FIPS 140-2

FIPS 140-2 (Federal Information Processing Standard 140-2) is the US government standard for cryptographic module validation. It defines four security levels. Levels 2 and 3 are most common in enterprise contexts:

FIPS 140-2 Level 2 — requires physical tamper evidence (seals, locks) on the cryptographic module; software cryptographic libraries validated at this level are acceptable for US federal procurement
FIPS 140-2 Level 3 — requires stronger physical tamper resistance and zeroisation of key material on intrusion detection; required for HSMs handling the most sensitive key material

“The customer requires FIPS 140-2 Level 3 for their regulated data workload — we need to route their encryption operations through the HSM cluster, not the software KMS.”

Security Discussion Language

Cryptographic design decisions need to be communicated precisely, especially in security reviews and architecture sign-offs.

Security Review Vocabulary

Threat model — a structured analysis of potential attackers, their capabilities, and the assets they might target
Attack surface — the totality of exposed interfaces and code paths through which an attacker could interact with the system
Trust boundary — a line in the architecture where data or control crosses between two different levels of trust; every trust boundary crossing requires validation

Explaining Cryptographic Trade-offs

Avoid vague justifications in security discussions. Use the pattern: “We chose X over Y because [specific property difference]; the trade-off is [cost, complexity, or performance].”

“We chose AES-256-GCM over AES-CBC because we need authenticated encryption — CBC provides confidentiality but no integrity guarantee; a separate HMAC is required for integrity, which adds complexity and must be implemented correctly to avoid padding oracle vulnerabilities. GCM provides both in a single pass and is faster in practice.”

Side-Channel Attacks

A side-channel attack exploits information leaked through the physical or computational behaviour of a system — timing, power consumption, electromagnetic emissions — rather than weaknesses in the cryptographic algorithm itself.

A timing attack is the most common application-layer side-channel: if a comparison function returns early on the first differing byte, an attacker can determine how many bytes matched by measuring response time across many requests.

The defence is constant-time comparison: comparison functions that execute the same number of operations regardless of where the inputs diverge.

“We use constant-time comparison for HMAC validation throughout the authentication path — variable-time string comparison is exploitable via timing side-channel, and this has been demonstrated against real authentication systems.”

Vulnerability Disclosure Language

When communicating security findings, precision in severity framing affects how quickly issues get prioritised:

“This is a low-severity cryptographic weakness — the cipher suite is technically deprecated but there is no known practical exploit path given the key sizes in use. With that said, we should rotate to the recommended algorithm within the quarter to maintain a defensible posture ahead of the next compliance audit.”

The pattern: severity + justification + recommended action + timeframe. Avoid catastrophising low-severity findings or minimising high-severity ones.

Cryptography vocabulary is the difference between participating in a security review and sitting through one. For practice with these terms in realistic engineering conversations, explore the CoderLingo security vocabulary exercises and cryptography interview preparation.