X.509 is the ITU-T standard (first published in 1988, currently at version 3) that defines the structure of a digital certificate: a signed data structure that binds a public key to an identity and a set of constraints, issued by a Certificate Authority whose signature vouches for the binding. It is the near-universal format for certificates in PKI, TLS, code signing, S/MIME encrypted email, SPIFFE X.509-SVIDs, and SSH host certificates. When someone refers to a TLS certificate, a CA certificate, or a code-signing certificate, they are referring to an X.509 certificate. The format is defined using ASN.1 (Abstract Syntax Notation One) and most commonly serialised as DER (Distinguished Encoding Rules, binary) or PEM (base64-wrapped DER with -----BEGIN CERTIFICATE----- headers, the format seen in most configuration files).
WireGuard is a VPN protocol and implementation designed by Jason Donenfeld, merged into the Linux kernel in 5.6 (2020) and subsequently ported to Windows, macOS, iOS, Android, and BSD. Its defining characteristic is radical simplicity: the reference Linux kernel implementation is approximately 4,000 lines of code, compared to tens of thousands for IPsec’s XFRM subsystem and hundreds of thousands for OpenVPN. This simplicity is a deliberate security property — a smaller codebase has a smaller attack surface, is easier to audit, and is less likely to contain implementation vulnerabilities. WireGuard achieves this by making every design decision that allows optionality to be eliminated: there is no algorithm negotiation, no handshake negotiation, no cipher suite selection. The cryptographic suite is fixed: X25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and key derivation (via a custom HKDF-like construction), and Curve25519 for the static key pairs that identify peers. Peers are identified exclusively by their 32-byte Curve25519 public key, making WireGuard a public-key routed VPN: there are no usernames, passwords, certificates, or CAs; access control is entirely a function of which public keys are listed in each peer’s configuration.
TLS (Transport Layer Security) is the protocol that establishes an encrypted, integrity-protected, and authenticated channel between two parties over an untrusted network. It is the successor to SSL (which is deprecated and broken) and the mechanism behind HTTPS, gRPC, LDAPS, SMTPS, database connections, and most other encrypted transport in modern infrastructure. The current version is TLS 1.3 (RFC 8446, 2018); TLS 1.2 remains in wide use but TLS 1.0 and 1.1 are deprecated by RFC 8996. The fundamental security properties TLS provides are: confidentiality (a passive observer cannot read the session content), integrity (an active attacker cannot modify session content without detection), and server authentication (the client can verify it is talking to the intended server rather than an impersonator). Client authentication is optional in standard TLS and is provided by mTLS.
SSH (Secure Shell) is a cryptographic protocol, standardised in RFC 4251–4254, that provides a secure channel over an unsecured network for remote login, remote command execution, file transfer (via SFTP and SCP), and general TCP port forwarding. It replaced the plaintext protocols it was designed to obsolete — Telnet, rlogin, rsh, rcp — by providing mutual authentication and full session encryption. SSH is the universal administrative access mechanism for Linux servers, network devices, and embedded systems, and the transport layer for Git over SSH, Ansible, Fabric, and most configuration management tooling. The protocol stack has three layers: SSH-TRANS (the transport layer — handles the initial key exchange, server authentication, and establishes the encrypted channel), SSH-AUTH (the authentication protocol — authenticates the client to the server using one of several methods), and SSH-CONN (the connection protocol — multiplexes the encrypted channel into multiple logical channels for sessions, port forwards, and X11 forwarding).
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardised as NIST FIPS 205 in August 2024, is the post-quantum signature standard based on hash functions rather than lattice problems. Where ML-DSA and ML-KEM both rest their security on the hardness of Module Learning With Errors — a relatively young mathematical assumption first formulated in 2005 — SLH-DSA’s security rests exclusively on the collision resistance and preimage resistance of an underlying hash function (SHA-256, SHA-512, or SHAKE, depending on parameter set). Hash function security against quantum computers is well-understood: Grover’s algorithm provides at most a quadratic speedup, which is fully mitigated by doubling output size (SHA-256 remains adequate against classical attacks; SHA-512 provides AES-256-equivalent quantum resistance). The decades-long cryptanalytic confidence in SHA-2 and SHA-3 makes SLH-DSA’s security argument the most conservative available: it requires no new mathematical assumption beyond the hash functions already trusted throughout the entire cryptographic stack.
SHA (Secure Hash Algorithm) is the name given to a series of cryptographic hash function families standardised by NIST under FIPS 180 and FIPS 202. Three generations exist with fundamentally different design lineages. SHA-1 (1995, FIPS 180-1) produces a 160-bit digest and is fully broken for collision resistance: the SHAttered attack (Google and CWI Amsterdam, 2017) produced a chosen-prefix collision — two different PDF files with identical SHA-1 hashes — using approximately 9.2 × 10^18 SHA-1 operations, within practical reach of well-resourced attackers. SHA-1 must not be used for any security purpose; it persists only in legacy Git object identifiers (SHA-1 is being phased out in Git’s object store in favour of SHA-256 under the sha256 object format) and in TOTP’s HMAC-SHA-1 inner construction (where collision resistance is not the relevant security property, but migration to SHA-256 variants is still recommended). SHA-2 (2001, FIPS 180-2 and subsequent revisions) is the Merkle-Damgård family that includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 and SHA-512 are the two variants in universal production use; the others serve niche roles. SHA-3 (2015, FIPS 202) is the Keccak sponge construction — structurally independent of SHA-2 — providing algorithm diversity and including fixed-output variants (SHA3-256, SHA3-512) and extendable output functions (SHAKE128, SHAKE256).
RSA (Rivest–Shamir–Adleman), published in 1977, was the first widely adopted public-key cryptosystem and for decades the most deployed asymmetric algorithm in existence. Its security rests on the integer factorisation problem: given a public modulus n = p × q (the product of two large primes), recovering p and q is computationally infeasible on classical computers for sufficiently large n. The public key is the pair (n, e) and the private key is (n, d), where e and d are related by the modular arithmetic of Euler’s totient function. RSA enables two operations: encryption (the sender uses the public key to encrypt a message that only the private key holder can decrypt) and signing (the private key holder produces a signature that anyone with the public key can verify). In practice, RSA encryption is used almost exclusively for key encapsulation — encrypting a randomly generated symmetric key — rather than encrypting arbitrary data directly, both because RSA is slow and because direct RSA encryption of large messages requires padding schemes that are historically error-prone.
Post-Quantum Cryptography (PQC) is the set of cryptographic algorithms designed to resist attacks from a Cryptographically Relevant Quantum Computer (CRQC) — a quantum computer large and stable enough to run Shor’s algorithm at scale. Shor’s algorithm can solve the integer factorisation and discrete logarithm problems that underpin RSA, ECDSA, and ECDH in polynomial time, meaning that every asymmetric algorithm in wide use today — TLS key exchange, X.509 certificate signatures, SSH host keys, code signing, and encrypted email — becomes trivially breakable by a CRQC. Symmetric algorithms (AES, SHA-256) are substantially less affected: Grover’s algorithm provides only a quadratic speedup against them, which is mitigated by doubling key lengths (AES-256 remains appropriate). PQC replaces the asymmetric primitives only, on hard mathematical problems for which no efficient quantum algorithm is known: structured lattices (the Learning With Errors and Module-LWE problems), hash functions (the security of SHA-3 family variants), and error-correcting codes.
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.
OpenSSL is an open-source cryptographic library and command-line toolkit, originally derived from SSLeay in 1998 and now governed by the OpenSSL Software Foundation under an Apache 2.0 licence (since version 3.0). It is the default cryptographic substrate for the majority of Linux server software: Apache httpd, nginx, curl, wget, PostgreSQL, MySQL, Postfix, OpenLDAP, and hundreds of other projects link against libssl and libcrypto by default. It implements TLS (all versions from 1.2 through 1.3), X.509 certificate parsing and validation, PKI operations (CSR generation, certificate signing, CRL and OCSP processing), and the full range of cryptographic primitives — symmetric ciphers (AES-GCM, ChaCha20-Poly1305), hash functions (SHA-2, SHA-3, SHAKE), RSA, ECC (ECDSA, ECDH, Ed25519, X25519), HMAC, HKDF, and key derivation functions. The library has two primary components: libcrypto, the algorithm library, and libssl, the TLS protocol layer built on top of it. The openssl command-line tool exposes both as a single swiss-army interface for certificate management, key generation, encryption, hashing, benchmarking, and protocol testing.
OpenPGP is an open standard for encryption and digital signatures of arbitrary data, defined in RFC 4880 (2007) and substantially revised in RFC 9580 (2024, adding Ed25519, X25519, and modern AEAD encryption). GnuPG (GPG) is the dominant open-source implementation, maintained by Werner Koch and the GnuPG project, and the tool most users interact with. OpenPGP predates the PKI/CA model and takes a fundamentally different approach to trust: rather than a hierarchy of certificate authorities that users must trust transitively, OpenPGP uses a Web of Trust in which individual users sign each other’s public keys, and trust is established through chains of personal endorsements. In the Web of Trust model, Alice trusts Bob’s key because she verified it in person and signed it; Carol trusts Bob’s key because Alice (whom Carol trusts) signed it. This decentralised, peer-to-peer trust model made sense for email encryption between individuals who could meet at key-signing parties, but does not scale to automated infrastructure verification, which is why OpenPGP’s role in modern infrastructure is primarily supply chain signing — package repositories, Git commits, and release artifacts — rather than interactive authentication.
mTLS (Mutual TLS) is the configuration of TLS in which certificate-based authentication is required from both sides of the connection, not just the server. In standard TLS, only the server presents an X.509 certificate, which the client verifies to confirm it is talking to the intended host; the client is typically anonymous to the server, or authenticates separately via a password or session token at the application layer. In mTLS, the client also presents a certificate during the TLS handshake; the server verifies it against a trusted CA before completing the connection. The result is cryptographic proof of identity in both directions: the client knows it is talking to the legitimate server (as in standard TLS), and the server knows the exact identity of the connecting client — without any password, API key, or token exchanged in the application layer.
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as NIST FIPS 203 in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of ECDH (X25519, P-256) and RSA key transport in TLS handshakes, IPsec IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST’s lattice-based KEM selection, and its security rests on the Module Learning With Errors (MLWE) problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The “module” qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).
ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as NIST FIPS 204 in August 2024, is the primary post-quantum replacement for digital signatures. It replaces ECDSA, EdDSA, and RSA PSS/PKCS#1 signatures in X.509 certificates, code signing, TLS client and server authentication, SSH, JWT signing, and any other context where a party proves possession of a private key by producing a signature that others verify with the public key. ML-DSA is derived from CRYSTALS-Dilithium, the submission that won NIST’s lattice-based signature selection, and its security rests on the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems — the same mathematical family as ML-KEM, which is significant because both algorithms can share implementation code and hardware acceleration for the underlying polynomial arithmetic (NTT, number-theoretic transform).
JWT (JSON Web Token), standardised in RFC 7519, is a compact, self-contained token format that encodes a set of claims — assertions about a subject, an issuer, an audience, and arbitrary application-defined attributes — as a JSON object, signs or encrypts it, and serialises the result as three base64url-encoded segments separated by dots: header.payload.signature. The header is a JSON object specifying the algorithm (alg) and optionally a key ID (kid) used to produce the signature. The payload is a JSON object containing the claims. The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm declared in the header. The entire token is URL-safe, fits in an HTTP header or query parameter, and is self-describing — a verifier can locate the signing key, check the algorithm, verify the signature, and read the claims without any external lookup beyond fetching the issuer’s public key. This self-contained nature is what makes JWTs efficient at scale: unlike opaque tokens, which require a network call to the issuer’s introspection endpoint per verification, a JWT can be verified locally with a cached public key, making it suitable for high-throughput API gateways and distributed systems.
IPsec (Internet Protocol Security) is a suite of IETF standards (core specification RFC 4301) that adds cryptographic security to IP packets at the network layer, transparently to applications running above it. Where TLS secures a specific connection between two application endpoints, IPsec secures all IP traffic between two hosts or networks — including traffic from applications that have no TLS support, protocols that predate encryption (routing protocols, SNMP, ICMP), and layer-3 metadata that TLS cannot protect. IPsec provides two protocol headers: AH (Authentication Header, IP protocol 51) signs the IP packet including immutable header fields, providing integrity and source authentication without confidentiality — rarely used in modern deployments because NAT rewrites fields that AH covers. ESP (Encapsulating Security Payload, IP protocol 50) encrypts the payload and provides authenticated encryption with AES-GCM or ChaCha20-Poly1305, optionally protecting the inner IP header as well; ESP is the universally deployed choice. Both operate in two modes: transport mode protects only the payload of an existing IP packet (used for host-to-host encryption between endpoints that share routing), and tunnel mode encapsulates the entire original IP packet inside a new one with new source and destination addresses — the basis of VPN gateways where traffic from one network is tunnelled to another through the public internet.
A Hardware Security Module (HSM) is a purpose-built, tamper-resistant hardware device that holds cryptographic keys and performs cryptographic operations — signing, encryption, decryption, random number generation — entirely within its own protected boundary. The defining property is that private keys generated inside an HSM never exist in plaintext outside it: operations that need the key are sent into the HSM and the result is returned, but the key material itself cannot be extracted. This property is enforced both logically (the firmware refuses export in plaintext) and physically (the device detects and responds to tampering by erasing key material before an attacker can read it). HSMs come in several physical forms: network-attached appliances (rack-mounted devices accessed over the network by many clients), PCIe cards (embedded in a server), and compact USB devices for lower-throughput use cases like protecting CA root keys offline.
HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.
A cryptographic hash function maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length digest (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. Preimage resistance: given a digest h, it is computationally infeasible to find any input m such that H(m) = h. Second preimage resistance: given an input m1, it is computationally infeasible to find a different input m2 such that H(m1) = H(m2). Collision resistance: it is computationally infeasible to find any pair (m1, m2) with m1 ≠ m2 such that H(m1) = H(m2). Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.
FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.
