Cryptography on Le Site de François

AES (Advanced Encryption Standard)

Mon, 01 Jan 0001 00:00:00 +0000

AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.

Diffie-Hellman (DH / ECDH / X25519)

Mon, 01 Jan 0001 00:00:00 +0000

Diffie-Hellman (DH) is a key exchange protocol published by Whitfield Diffie and Martin Hellman in 1976 — the first public description of asymmetric cryptography and one of the most consequential cryptographic publications in history. Its fundamental contribution is solving the key establishment problem: two parties who have never communicated before, communicating over a channel that an adversary can fully observe, can nonetheless agree on a shared secret that the adversary cannot determine. The security of finite-field DH rests on the discrete logarithm problem: given g^a mod p and g^b mod p (the public values exchanged), computing g^ab mod p (the shared secret) requires solving for either a or b, which is computationally infeasible for sufficiently large groups. The 1976 original uses multiplicative groups of integers modulo a prime p; the security level is determined by the size of p (currently 2048-bit minimum, 3072-bit recommended) and the group’s structure. Finite-field DH is still deployed in TLS 1.2 DHE cipher suites and legacy IPsec configurations, but has been supplanted in new deployments by Elliptic Curve Diffie-Hellman (ECDH) and specifically by X25519, which provide equivalent security at dramatically smaller key sizes.

ECC (Elliptic Curve Cryptography)

Mon, 01 Jan 0001 00:00:00 +0000

Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic curve analogue of DSA, standardised in FIPS 186 and the IETF, that produces digital signatures using a private key and verifies them with the corresponding public key. It is the most widely deployed signature algorithm in X.509 certificates (P-256 with SHA-256 is the default for certificate authorities issuing TLS certificates), in code signing (Authenticode, macOS, Linux package signing), in TLS 1.3 certificate authentication, in SSH host keys and user keys (though Ed25519 is increasingly preferred), and in blockchain and cryptocurrency systems. An ECDSA signature over a message m with private key d on curve with base point G produces a pair (r, s), where r is the x-coordinate of an ephemeral public key k × G and s encodes the relationship between the message hash, r, the private key d, and the nonce k. Verification requires only the public key Q = d × G and is fast; signing requires the private key and a nonce.

FIDO (Fast IDentity Online) / FIDO2

Mon, 01 Jan 0001 00:00:00 +0000

FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.

FIPS 140-2 / FIPS 140-3

Mon, 01 Jan 0001 00:00:00 +0000

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.

Hash Function (Cryptographic Hash Function)

Mon, 01 Jan 0001 00:00:00 +0000

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.

HMAC (Hash-based Message Authentication Code)

Mon, 01 Jan 0001 00:00:00 +0000

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.

HSM (Hardware Security Module)

Mon, 01 Jan 0001 00:00:00 +0000

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.

IPsec (Internet Protocol Security)

Mon, 01 Jan 0001 00:00:00 +0000

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.

JWT (JSON Web Token)

Mon, 01 Jan 0001 00:00:00 +0000

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.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

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).

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

Mon, 01 Jan 0001 00:00:00 +0000

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).

mTLS (Mutual TLS)

Mon, 01 Jan 0001 00:00:00 +0000

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.

OpenPGP / GPG

Mon, 01 Jan 0001 00:00:00 +0000

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.

OpenSSL

Mon, 01 Jan 0001 00:00:00 +0000

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.

PKI (Public Key Infrastructure)

Mon, 01 Jan 0001 00:00:00 +0000

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.

PQC (Post-Quantum Cryptography)

Mon, 01 Jan 0001 00:00:00 +0000

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.

RSA (Rivest–Shamir–Adleman)

Mon, 01 Jan 0001 00:00:00 +0000

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.

SHA (Secure Hash Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

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).

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

Mon, 01 Jan 0001 00:00:00 +0000

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.

SSH (Secure Shell)

Mon, 01 Jan 0001 00:00:00 +0000

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).

TLS (Transport Layer Security)

Mon, 01 Jan 0001 00:00:00 +0000

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.

WireGuard

Mon, 01 Jan 0001 00:00:00 +0000

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.

X.509

Mon, 01 Jan 0001 00:00:00 +0000

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).