Reference

Glossary

302 terms of digital signatures, certificates, tokens, protocols and post-quantum cryptography, each defined in a few sentences and tied to the standards that specify it.

302 of 302 shown

A to Z

A

AAGUID (Authenticator Attestation GUID): The 16-byte identifier in a WebAuthn credential's attested data that names the authenticator model, such as a particular security key or password manager, used to look up metadata and icons.
Access token: The credential an OAuth client presents to a resource server to call an API on behalf of a user or itself, either an opaque string checked by introspection or a self-contained JWT.
ACME (Automatic Certificate Management Environment): The protocol of RFC 8555, created for Let's Encrypt, in which a client proves control of identifiers through challenges and obtains certificates from a CA without human involvement.
ACME dns-01 challenge: The ACME domain-validation method in which the client publishes a TXT record at _acme-challenge.domain containing base64url(SHA-256(key authorization)), the only ACME method that can validate wildcard names.
ACME http-01 challenge: The ACME domain-validation method in which the client serves the key authorization at http://domain/.well-known/acme-challenge/token on port 80 and the CA fetches it from several network vantage points.
ACME Renewal Information (ARI): The ACME extension of RFC 9773 (June 2025) through which a CA tells clients the window in which each certificate should be renewed, so the CA can spread load and request early renewal before mass revocations.
AEAD (authenticated encryption with associated data): A symmetric encryption mode that provides confidentiality and integrity in one operation and additionally authenticates unencrypted associated data such as headers, defined generically in RFC 5116.
AES-GCM: AES in Galois/Counter Mode (NIST SP 800-38D), the most widely deployed AEAD: counter-mode encryption plus a GHASH authenticator, normally with a 96-bit nonce and a 128-bit tag.
age (file encryption): A small, modern file encryption tool and format (age-encryption.org/v1) by Filippo Valsorda that encrypts to X25519, SSH or post-quantum hybrid recipients or to a passphrase, with no signatures and no configuration.
alg (JOSE algorithm header): The JOSE header parameter that names the signature or MAC algorithm of a JWS (for example ES256) or the key management algorithm of a JWE (for example RSA-OAEP-256), registered by RFC 7518 and later RFCs.
alg none (unsecured JWS): The JWS algorithm value none (RFC 7518 §3.6) that denotes an unsigned token with an empty signature part, which a verifier must never accept unless it explicitly expects unsecured content.
Algorithm confusion (key confusion): A verification flaw in which a library lets the token's alg header choose the algorithm, so a key meant for one algorithm is used with another, classically an RSA public key used as an HS256 secret.
ALPN (Application-Layer Protocol Negotiation): The TLS extension of RFC 7301 in which the client offers application protocols such as h2 and http/1.1 and the server picks one inside the handshake, avoiding an extra round trip.
APK Signature Schemes (v1–v4): Android's app-signing formats: v1 JAR signing, v2 (Android 7.0) and v3 (Android 9, key rotation) whole-file signatures in the APK Signing Block, v3.1 (Android 13) targeted rotation and v4 (Android 11) for incremental installs.
Apple notarization: Apple's automated malware scan for Developer ID-signed Mac software: developers upload builds with notarytool, Apple returns a ticket that Gatekeeper checks, and the ticket can be stapled to the app or installer.
ARC (Authenticated Received Chain): The experimental protocol of RFC 8617 (2019) in which each intermediary that handles a message records the authentication results it saw and seals them, so a final receiver can trust results that forwarding or mailing lists later broke.
ASCII armor: OpenPGP's text encoding of binary packets as base64 between lines such as -----BEGIN PGP PUBLIC KEY BLOCK----- and -----END PGP PUBLIC KEY BLOCK----- (RFC 9580 §6.2).
ASN.1 (Abstract Syntax Notation One): The ITU-T X.680 language for describing data structures independently of their encoding, used to define X.509 certificates, CMS, PKCS #8 keys, OCSP, LDAP and telecom protocols.
Attestation (WebAuthn): A statement, signed by an authenticator's attestation key at registration, that tells a relying party what kind of authenticator created a credential, so it can enforce device policies.
aud (audience claim): The registered JWT claim (RFC 7519 §4.1.3) naming the recipients a token is intended for, as a string or an array of strings, which every recipient must check contains its own identifier.
Authenticator (FIDO/WebAuthn): The component that holds WebAuthn credentials and produces signatures — a platform authenticator built into a device, a roaming security key, or a credential manager that syncs passkeys.
Authenticator data: The binary structure every WebAuthn response carries: a 32-byte SHA-256 of the RP ID, a flags byte, a 4-byte signature counter and, optionally, attested credential data and CBOR extension outputs.
Authenticode: Microsoft's code-signing format for Windows executables, drivers, installers and scripts: a PKCS #7 SignedData over a hash of the file, embedded in the PE certificate table and usually timestamped.

B

Base64url: The URL- and filename-safe base64 alphabet of RFC 4648 §5, which replaces + and / with - and _ and, in JOSE, drops the = padding; every part of a JWT is base64url-encoded.
Baseline Requirements (BR): The CA/Browser Forum's rules for issuing and managing publicly trusted TLS server certificates, covering validation methods, certificate profiles, lifetimes, revocation and CA operations.
Basic constraints: The X.509 extension (OID 2.5.29.19) whose cA flag says whether a certificate belongs to a CA allowed to sign other certificates, with an optional pathLenConstraint limiting how many CAs may follow it.
Bearer token: An access token that grants access to whoever presents it, without proof of possession of any key (RFC 6750), typically sent as Authorization: Bearer followed by the token.
BIMI (Brand Indicators for Message Identification): A DNS record and certificate scheme, still an IETF Internet-Draft, that lets a domain with DMARC at enforcement show its logo next to messages in supporting mailboxes such as Gmail, Yahoo and Apple Mail.
BIP-32 (hierarchical deterministic wallets): The Bitcoin standard for deriving a tree of keys from one seed with HMAC-SHA512 and chain codes, so one backup covers all addresses and extended public keys can derive receive addresses without private keys.
BIP-39 (mnemonic seed phrases): The standard that encodes wallet entropy as 12–24 words from a 2,048-word list and stretches the phrase with PBKDF2-HMAC-SHA512 (2,048 iterations) into the 64-byte seed used by BIP-32.
BIP-137 (signed message format): The Bitcoin message-signing format that uses a 65-byte recoverable ECDSA signature whose header byte encodes both the recovery id and the address type: 27–30 P2PKH uncompressed, 31–34 compressed, 35–38 P2SH-P2WPKH, 39–42 P2WPKH.
BIP-322 (generic signed message format): The Bitcoin message-signing standard that proves control of any address type, including SegWit, Taproot and multisig, by signing a virtual transaction that spends from the address.
BIP-340 (Schnorr signatures for secp256k1): The Bitcoin specification of 64-byte Schnorr signatures over secp256k1 with 32-byte x-only public keys and tagged hashes, used by Taproot and by Nostr.
Bitcoin address: A human-readable encoding of a Bitcoin output script: legacy P2PKH (1…) and P2SH (3…) in Base58Check, SegWit v0 (bc1q…) in bech32 and Taproot (bc1p…) in bech32m.
BLAKE2: A fast hash function family (BLAKE2b for 64-bit platforms with digests up to 64 bytes, BLAKE2s for 32-bit with up to 32 bytes), specified in RFC 7693 and used in Argon2, WireGuard, PASETO and libsodium.
Blind signing: Approving a transaction or message whose meaning the signing device cannot show, typically only a hash or raw calldata, so the signer must trust the possibly compromised computer that prepared it.
BLS signatures: Pairing-based signatures (Boneh, Lynn and Shacham, 2001) that are short, deterministic and natively aggregatable, used most prominently by Ethereum's proof-of-stake consensus on the BLS12-381 curve.
Brainpool curves: A family of elliptic curves with verifiably pseudo-random parameters (RFC 5639, 2010), favored by German and other European government profiles as an alternative to the NIST curves.
Build provenance: A signed, verifiable record of how an artifact was produced — source repository and commit, build platform, workflow and inputs — that lets consumers check that a package came from the expected source and pipeline.
Bulk sender requirements (Gmail, Yahoo, Microsoft): Rules that Gmail and Yahoo (from February 2024) and Microsoft (from May 2025) enforce on senders of more than about 5,000 messages a day: SPF, DKIM, an aligned DMARC record and one-click unsubscribe.

C

C2PA (Content Credentials): The Coalition for Content Provenance and Authenticity's standard for signed provenance manifests embedded in images, video, audio and documents, recording who created or edited content and with what tools, including AI generation.
CA (certificate authority): An organization or service that issues and signs certificates after checking that the requester controls the names or identity the certificate will assert.
CA/Browser Forum: The voluntary body of certificate authorities and browser and operating system vendors that writes the Baseline Requirements and other rules for publicly trusted TLS, S/MIME and code-signing certificates.
CAA (Certification Authority Authorization): A DNS record type (RFC 8659) with which a domain owner lists the CAs allowed to issue certificates for its names, which every public CA must check before issuance.
Canonicalization: Transforming data into one agreed byte representation before hashing or signing, so that semantically equal inputs (different whitespace, key order, namespace prefixes or header folding) produce the same signature input.
CBOM (cryptographic bill of materials): A machine-readable inventory of the cryptographic assets in a system — algorithms, keys, certificates, protocols and libraries with their parameters — used to plan and track migrations such as the move to post-quantum cryptography.
Certificate (public key certificate): A signed statement by an issuer that a given public key belongs to a named subject, valid for a limited time and for stated purposes, most often in X.509 format.
Certificate chain: The ordered sequence of certificates from an end-entity (leaf) certificate through one or more intermediate CA certificates to a trusted root, each signed by the next.
Certificate lifetime (validity period): The span from a certificate's notBefore to its notAfter, inclusive; for publicly trusted TLS certificates the maximum is 200 days since 15 March 2026, falling to 100 days in 2027 and 47 days in 2029.
Certificate or public key pinning: Restricting which certificates or public keys a client accepts for a host to a fixed set, beyond ordinary chain validation, by matching hashes of a CA key, an intermediate or the server's own key.
Certificate serial number: The positive integer, unique per issuer and at most 20 octets long, that identifies a certificate in CRLs, OCSP requests and incident reports.
Certificate Transparency (CT): The system of public, append-only Merkle-tree logs (RFC 6962) to which CAs submit every publicly trusted TLS certificate, so that domain owners and monitors can detect misissued certificates.
Certification path validation: The algorithm of RFC 5280 §6 that decides whether a chain from a trust anchor to an end-entity certificate is valid, checking signatures, validity periods, names, constraints, policies and revocation.
ChaCha20-Poly1305: The AEAD combining the ChaCha20 stream cipher with the Poly1305 authenticator (RFC 8439): 256-bit keys, 96-bit nonces and 128-bit tags, fast in software without AES hardware.
Cipher suite: A named combination of cryptographic algorithms used by a TLS connection; in TLS 1.3 it names only the AEAD and the handshake hash (for example TLS_AES_128_GCM_SHA256), while TLS 1.2 names also fixed the key exchange and authentication.
ClientHello: The first TLS handshake message, sent in clear text, in which the client lists its supported versions, cipher suites, groups, signature algorithms, key shares and extensions such as the server name.
CMS (Cryptographic Message Syntax): The IETF successor of PKCS #7 (RFC 5652) for signed, enveloped and authenticated data, used by S/MIME, Authenticode, PDF signatures, RFC 3161 timestamps and many firmware formats.
CNSA 2.0: The NSA's Commercial National Security Algorithm Suite 2.0 (September 2022), which requires ML-KEM-1024, ML-DSA-87, LMS or XMSS, AES-256 and SHA-384 or SHA-512 in US national security systems by 2030–2035.
Code signing: Signing executables, packages, scripts or firmware so that operating systems, stores and users can verify the publisher and detect tampering, using X.509 certificates, platform keys, OpenPGP or Sigstore.
Cofactor: The ratio h = #E / n between the number of points on an elliptic curve and the prime order n of the subgroup used for cryptography: 1 for the NIST P-curves and secp256k1, 8 for Curve25519, 4 for Curve448.
Composite signatures: Signatures that combine a post-quantum and a classical algorithm under one key and one algorithm identifier — for example ML-DSA-65 with ECDSA P-256 — so a signature verifies only if both components verify.
COSE (CBOR Object Signing and Encryption): The CBOR-based counterpart of JOSE (RFC 9052 and RFC 9053) for signatures, MACs, encryption and keys, used by WebAuthn, mdoc driver's licenses, CWTs and C2PA.
cosign: Sigstore's command-line tool for signing and verifying container images, blobs and attestations, either with keys or keylessly with OIDC identities and short-lived certificates.
CRL (certificate revocation list): A list of revoked certificate serial numbers, signed and periodically published by a CA (RFC 5280 §5), that verifiers download to check revocation without querying the CA per certificate.
CRLite: Firefox's revocation mechanism that compresses the revocation status of every Certificate Transparency-logged certificate into compact filters downloaded to the browser and queried locally.
Crypto-agility: The ability of a system to change cryptographic algorithms, key sizes and parameters without redesign — through negotiation, configuration and inventory — which the post-quantum transition turns from a best practice into a necessity.
Cryptographic hash function: A function that maps input of any length to a fixed-length digest such that finding a preimage, a second preimage or any collision is computationally infeasible.
CSPRNG (cryptographically secure random number generator): A random number generator whose output cannot be predicted or distinguished from true randomness even by an attacker who has seen previous outputs, required for keys, nonces, salts and tokens.
CSR (certificate signing request): A PKCS #10 message (RFC 2986) containing a subject name, a public key and requested attributes, signed with the matching private key to prove possession, which a CA turns into a certificate.
CTAP (Client to Authenticator Protocol): The FIDO Alliance protocol between a client (browser or operating system) and an external authenticator over USB HID, NFC, Bluetooth or the hybrid phone transport, with CBOR-encoded commands such as authenticatorMakeCredential.
Curve25519: Daniel J. Bernstein's 2005 Montgomery curve y² = x³ + 486662x² + x over the prime 2²⁵⁵ − 19, the basis of X25519 key exchange and, in Edwards form, of Ed25519 signatures.
CWT (CBOR Web Token): The CBOR counterpart of JWT (RFC 8392): a claims set encoded as a CBOR map with integer claim keys and protected by COSE signing, MAC or encryption.

D

DANE (DNS-based Authentication of Named Entities): The use of DNSSEC-signed TLSA records (RFC 6698, RFC 7671) to state which certificate or public key a TLS service must present, either alongside or instead of public CAs.
DER (Distinguished Encoding Rules): The canonical binary encoding of ASN.1 from ITU-T X.690 that gives every value exactly one byte representation, which is why certificates, CSRs, CRLs, keys and many signatures are DER-encoded.
Detached signature: A signature stored separately from the data it signs — such as an OpenPGP .sig or .asc file, an SSHSIG file or a CMS signature without encapsulated content — so the original file stays unchanged.
DID (decentralized identifier): A URI of the form did:method:identifier (W3C DID Core 1.0, 2022) that resolves to a DID document listing public keys and service endpoints, controlled by its subject rather than a central registry.
Digest (message digest): The fixed-length output of a cryptographic hash function over some data, used as a compact, collision-resistant identifier for that data and as the input that most signature schemes actually sign.
Digital signature: A value computed from a message with a private key that anyone holding the matching public key can check, proving that the message is unchanged and was signed by the key holder.
Discoverable credential (resident key): A WebAuthn credential whose private key and user handle are stored by the authenticator so it can be found without the server first sending a credential ID, which enables username-less passkey sign-in.
Distinguished name (DN): The X.500 hierarchical name used for the subject and issuer of a certificate, built from attribute–value pairs such as CN, O, OU, L, ST and C.
DKIM (DomainKeys Identified Mail): The e-mail authentication standard of RFC 6376 in which the sending domain signs selected headers and the body of a message and publishes the public key in DNS, so receivers can verify that the message came from that domain unaltered.
DKIM canonicalization: The two algorithms, simple and relaxed (RFC 6376 §3.4), that normalize a message's headers and body before DKIM hashing, chosen independently for headers and body with the c= tag.
DKIM replay: Re-sending a legitimately DKIM-signed message, unchanged, to many new recipients so that it carries the reputation of the signing domain, which DKIM cannot prevent because the signature does not cover the SMTP envelope.
DKIM-Signature header: The header field (RFC 6376 §3.5) that carries a DKIM signature as tag=value pairs, including v, a, c, d, s, h, bh, b and the optional i, l, t and x tags.
DMARC: Domain-based Message Authentication, Reporting and Conformance (RFC 9989, May 2026): a DNS policy that requires SPF or DKIM to pass in alignment with the visible From domain and tells receivers what to do with mail that fails.
DMARC identifier alignment: The DMARC requirement that the domain authenticated by SPF (the envelope sender) or by DKIM (the d= domain) matches the domain in the From header, either exactly (strict) or within the same organizational domain (relaxed).
DNSSEC: The DNS Security Extensions (RFC 4033–4035), which sign DNS record sets so validating resolvers can check that answers come unmodified from the zone owner, chained from the root zone's key.
DoH (DNS over HTTPS): The protocol of RFC 8484 that carries DNS queries and responses in HTTPS requests (media type application/dns-message), hiding them from on-path observers and letting web applications resolve names directly.
Domain validation (DV): The certificate validation level in which a CA verifies only that the applicant controls the domain names in the certificate, by DNS, HTTP or TLS-ALPN challenges, and nothing about the organization.
Downgrade protection: Mechanisms that stop an attacker from forcing two parties that support a strong protocol version or algorithm onto a weaker one, such as the TLS 1.3 sentinel in ServerHello.random.
DPoP (Demonstrating Proof of Possession): The OAuth mechanism of RFC 9449 that binds access and refresh tokens to a client-held key: every request carries a fresh signed DPoP proof JWT, so a stolen token alone is useless.
DSA (Digital Signature Algorithm): The finite-field discrete-logarithm signature algorithm of FIPS 186 (1994), withdrawn by FIPS 186-5 in 2023 for new signatures and kept only for verifying existing ones.

E

ECDH (Elliptic-Curve Diffie–Hellman): Key agreement in which each party combines its own elliptic-curve private key with the other's public key to compute the same shared secret, the x-coordinate of d_A·d_B·G.
ECDH-ES (JWE key agreement): The JWE key management family of RFC 7518 §4.6 in which the sender generates an ephemeral EC key, agrees a secret with the recipient's static key and derives the content key with the Concat KDF.
ECDHE (ephemeral elliptic-curve Diffie–Hellman): Elliptic-curve Diffie–Hellman with fresh key pairs for every handshake, the key exchange that gives TLS forward secrecy; in TLS 1.3 it runs over x25519, secp256r1 and similar groups.
ECDLP (elliptic-curve discrete logarithm problem): The problem of finding the scalar d from points G and Q = d·G on an elliptic curve, whose hardness is the security assumption behind ECDSA, EdDSA, ECDH and Schnorr signatures.
ECDSA (Elliptic Curve Digital Signature Algorithm): The elliptic-curve form of DSA, specified in FIPS 186-5 and SEC 1, whose signature is a pair of integers (r, s) computed with a private scalar and a fresh secret nonce.
ECDSA public key recovery: Computing the signer's public key from an ECDSA signature and the message hash (SEC 1 §4.1.6), which Ethereum and Bitcoin message signing use instead of transmitting the key.
ECH (Encrypted Client Hello): The TLS 1.3 extension of RFC 9849 that encrypts the real ClientHello, including the server name, to a key published in DNS, leaving only a shared public name visible to the network.
ecrecover: The Ethereum precompiled contract at address 0x01 (and Solidity's ecrecover function) that recovers the signer's address from a 32-byte hash and an ECDSA signature (v, r, s) on secp256k1.
Ed448: EdDSA over the Edwards448 "Goldilocks" curve with SHAKE256 (RFC 8032 §5.2), giving about 224-bit security with 57-byte public keys and 114-byte signatures.
Ed25519: EdDSA over the Edwards form of Curve25519 with SHA-512 (RFC 8032 §5.1), giving 32-byte public keys, 64-byte deterministic signatures and about 128-bit security.
EdDSA (Edwards-curve Digital Signature Algorithm): A Schnorr-style signature scheme over twisted Edwards curves, defined in RFC 8032 and approved in FIPS 186-5, whose two standard instances are Ed25519 and Ed448.
eIDAS: The EU regulation on electronic identification and trust services (No 910/2014, amended by 2024/1183), under which qualified electronic signatures have the legal effect of handwritten ones.
EIP-155 (replay protection): The 2016 Ethereum change (Spurious Dragon, block 2,675,000) that puts the chain ID into the transaction signing hash and the v value (v = chainId × 2 + 35 or 36), so a transaction for one chain is invalid on others.
EIP-191 (signed data standard): The Ethereum convention that signed messages start with the byte 0x19 and a version byte, so they can never be valid transactions; version 0x45 is the personal_sign format used by most wallets.
EIP-712 (typed structured data signing): The Ethereum standard for hashing and signing typed structured data with a domain separator, so wallets can display fields to users and signatures cannot be replayed across contracts or chains.
EIP-7702 (set code for EOAs): The Ethereum upgrade, live since the Pectra hard fork on 7 May 2025, that lets an externally owned account delegate its code to a contract through a signed authorization in a type 0x04 transaction.
Elliptic curve: The set of points satisfying a cubic equation such as y² = x³ + ax + b over a finite field, with a point-addition law that forms the group used by ECDSA, EdDSA and ECDH.
ERC-1271 (contract signature validation): The Ethereum standard by which smart-contract accounts validate signatures: a verifier calls isValidSignature(bytes32 hash, bytes signature) and treats the return value 0x1626ba7e as valid.
ES256: The JWS algorithm for ECDSA on curve P-256 with SHA-256 (RFC 7518 §3.4), whose signature is exactly 64 bytes of raw r‖s rather than DER, also COSE algorithm −7.
Ethereum address: A 20-byte account identifier: for externally owned accounts, the last 20 bytes of the Keccak-256 hash of the 64-byte uncompressed secp256k1 public key without its 0x04 prefix, written as 0x plus 40 hex digits.
EUDI Wallet (European Digital Identity Wallet): The identity wallet that every EU member state must offer to citizens under Regulation (EU) 2024/1183 (eIDAS 2), holding person identification data and attestations in SD-JWT VC and mdoc formats.
exp (expiration time claim): The registered JWT claim (RFC 7519 §4.1.4) giving the time, in seconds since the Unix epoch, on or after which the token must not be accepted.
Extended key usage (EKU): The X.509 extension (OID 2.5.29.37) listing the application purposes a certificate's key may serve, such as id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning or id-kp-emailProtection.
Extended validation (EV): The strictest TLS certificate validation level, defined by the CA/Browser Forum EV Guidelines, in which the CA verifies the organization's legal, physical and operational existence and records registration details in the certificate.

F

Falcon (FN-DSA): A compact lattice signature scheme over NTRU lattices, selected by NIST in 2022 and being standardized as FN-DSA in FIPS 206, which was still a draft in October 2026.
FIDO Metadata Service (MDS): The FIDO Alliance's signed feed of metadata statements for certified authenticators — AAGUIDs, attestation root certificates, capabilities and certification status — used to verify attestation.
FIDO2: The FIDO Alliance's umbrella name for passwordless public-key authentication made of the W3C WebAuthn API and the FIDO Client to Authenticator Protocol (CTAP 2.x).
FIPS 140-3: The US and Canadian standard for cryptographic modules (2019, aligned with ISO/IEC 19790), under which the CMVP validates hardware and software modules at security levels 1 to 4.
Forward secrecy: The property that compromise of long-term keys, such as a server's certificate key, does not expose past sessions, achieved by deriving each session's keys from ephemeral key exchange values that are then discarded.

G

Git commit signing: Signing Git commits and tags with OpenPGP, SSH (since Git 2.34) or X.509 keys so that hosting platforms and reviewers can verify who created them; configured with gpg.format and user.signingkey.
Grover's algorithm: Lov Grover's 1996 quantum search algorithm, which finds a marked item among N in about √N steps and therefore at most halves the effective bit security of symmetric keys and hash preimages.

H

Hardware wallet: A dedicated device that stores wallet keys in a secure element or isolated microcontroller, shows transaction details on its own screen and signs only after physical confirmation.
Harvest now, decrypt later: The strategy of recording encrypted traffic today in order to decrypt it once a quantum computer can break its key exchange, the reason post-quantum key exchange is being deployed before quantum computers exist.
Hash-based signatures: Signature schemes whose security depends only on properties of a hash function, built from one-time signatures and Merkle trees: stateful LMS and XMSS (SP 800-208) and stateless SLH-DSA (FIPS 205).
Hedged signatures: Signing in which the per-signature nonce is derived from the private key and the message together with fresh randomness, so the scheme stays safe if either the random number generator or the deterministic derivation is attacked.
Hidden number problem: The lattice problem of recovering a secret from many noisy linear relations that reveal a few of its bits, which turns small biases or leaks in ECDSA and DSA nonces into full private-key recovery.
HKDF: The HMAC-based extract-and-expand key derivation function of RFC 5869, which turns a shared secret such as an ECDH output into one or more uniformly random keys bound to a context string.
HMAC: The keyed-hash message authentication code of RFC 2104 and FIPS 198-1, computed as H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)), which proves integrity and origin to anyone who shares the secret key.
HQC (Hamming Quasi-Cyclic): A code-based key encapsulation mechanism that NIST selected on 11 March 2025 as a backup to ML-KEM, planned as FIPS 207; its draft standard had not been published by October 2026.
HS256: The JWS algorithm HMAC with SHA-256 (RFC 7518 §3.2), in which issuer and verifier share one secret key of at least 256 bits, so anyone who can verify a token can also mint one.
HSM (hardware security module): A tamper-resistant device or cloud service that generates and stores keys and performs cryptographic operations inside its boundary, so private keys cannot be exported in plaintext.
HSTS (HTTP Strict Transport Security): The HTTP response header of RFC 6797 that tells browsers to use only HTTPS for a host for a set time, refuse certificate-error click-through and upgrade any http:// link automatically.
HTTP Message Signatures: The IETF standard (RFC 9421, February 2024) for signing selected components of an HTTP request or response, carried in the Signature-Input and Signature header fields.
Hybrid key exchange: A key exchange that combines a classical algorithm such as X25519 with a post-quantum KEM such as ML-KEM, so the session stays secret as long as either component remains unbroken.

I

ID token: The JWT an OpenID Connect provider issues to a client to assert that a user authenticated, containing at least iss, sub, aud, exp and iat claims and signed by the provider.
in-toto: A CNCF-graduated framework for signed supply-chain statements whose attestation format, a Statement binding artifact digests to a typed predicate, carries SLSA provenance and SBOM attestations.
Intermediate CA: A CA certificate signed by a root or another intermediate whose key issues end-entity certificates, letting the root key stay offline.
Invalid-curve attack: An attack in which a peer sends a point that is not on the agreed curve, so an implementation that skips point validation computes on a weaker curve and leaks its private key piece by piece.
iss (issuer claim): The registered JWT claim (RFC 7519 §4.1.1) identifying who issued a token, which a verifier must compare exactly with the issuer whose keys it used to verify the signature.

J

JA4 (TLS client fingerprint): FoxIO's 2023 method for fingerprinting TLS clients from their ClientHello — protocol, version, SNI, counts and sorted hashes of cipher suites and extensions — designed to stay stable when browsers randomize extension order.
JOSE (JSON Object Signing and Encryption): The IETF family of JSON-based formats for signing, encrypting and representing keys — JWS, JWE, JWK, JWA and JWT (RFC 7515–7519) — and the working group that maintains them.
JWA (JSON Web Algorithms): RFC 7518, which defines the algorithm identifiers and parameters used by JWS, JWE and JWK, such as HS256, RS256, ES256, PS256, RSA-OAEP, ECDH-ES and A256GCM.
JWE (JSON Web Encryption): The JOSE format of RFC 7516 for encrypted content, whose compact form has five parts — header, encrypted key, IV, ciphertext and tag — and which separates key management (alg) from content encryption (enc).
JWK (JSON Web Key): The JSON representation of a cryptographic key defined in RFC 7517, with members such as kty, crv, x, y, n and e for public keys and d for the private part.
JWK thumbprint: A hash of a JWK's required members in a canonical JSON form (RFC 7638), usually SHA-256 base64url-encoded, used as a stable key identifier for kid values, DPoP bindings and ACME.
JWKS (JSON Web Key Set): A JSON object whose keys array holds public JWKs, typically served at the issuer's jwks_uri so that relying parties can verify tokens and follow key rotation.
JWS (JSON Web Signature): The JOSE format of RFC 7515 for content signed or MACed with JSON-described parameters, serialized compactly as header.payload.signature or as JSON with multiple signatures.
JWT (JSON Web Token): A compact, URL-safe token (RFC 7519) carrying a JSON object of claims, signed as a JWS or encrypted as a JWE, used for ID tokens, access tokens and many API sessions.

K

Keccak-256: The original Keccak hash with a 256-bit output and pre-standard padding, used by Ethereum for addresses, function selectors and signing hashes; it is not the same function as FIPS 202 SHA3-256.
KEM (key encapsulation mechanism): A public-key primitive in which Encaps turns a public key into a random shared secret plus a ciphertext and Decaps recovers the secret with the private key, replacing Diffie–Hellman in post-quantum key exchange.
Key binding (holder binding): Proof that the party presenting a credential controls a private key named in it, so a copied credential cannot be replayed by someone else, implemented by SD-JWT's key-binding JWT and mdoc's device authentication.
Key exchange (key establishment): A protocol step by which two parties obtain a shared secret over an insecure channel, by Diffie–Hellman key agreement or by key encapsulation, from which session keys are derived.
Key or certificate fingerprint: A short hash of a public key or certificate used to identify and compare it by eye or in configuration, such as SHA256:… for SSH keys or the SHA-256 of a certificate's DER bytes.
Key pair: A mathematically linked private key and public key generated together for one asymmetric algorithm and, ideally, one purpose such as signing or key agreement.
Key rotation: Replacing a cryptographic key with a new one on a schedule or after an incident while keeping verification working during the changeover, typically by publishing old and new keys side by side.
Key usage extension: The X.509 extension (OID 2.5.29.15) whose bits restrict what a certified key may do: digitalSignature, contentCommitment, keyEncipherment, keyAgreement, keyCertSign, cRLSign and others.
key_share extension: The TLS 1.3 extension (51) that carries the client's ephemeral public values for one or more groups and the server's single reply, letting the key exchange complete in the first round trip.
Keyless signing: Sigstore's signing model in which the signer authenticates with an OIDC identity, gets a certificate valid for minutes for an ephemeral key, and relies on a transparency log instead of protecting a long-lived private key.
kid (key ID): The JOSE header parameter and JWK member that names which key signed or encrypted a token, letting a verifier pick the matching key from a JWKS during rotation.
Kyber (CRYSTALS-Kyber): The round-3 NIST submission from which ML-KEM was derived; deployed early in hybrid TLS (X25519Kyber768Draft00) and not interoperable with standardized ML-KEM.

L

Lattice-based cryptography: Cryptography built on hard problems in high-dimensional lattices, such as Learning With Errors and the Short Integer Solution problem, the basis of ML-KEM, ML-DSA and FN-DSA.
Length-extension attack: An attack on Merkle–Damgård hashes such as MD5, SHA-1, SHA-256 and SHA-512 that computes H(secret ‖ m ‖ padding ‖ m′) from H(secret ‖ m) and the length of secret ‖ m, without knowing the secret.
LibrePGP: An OpenPGP specification maintained by GnuPG's author (draft-koch-librepgp) that continues the RFC 4880bis line with v5 keys and its own Kyber composite encryption, incompatible with RFC 9580's v6 keys.
LMS and HSS (Leighton–Micali signatures): The stateful hash-based signature scheme of RFC 8554 and NIST SP 800-208, in which a Merkle tree of Winternitz one-time keys signs a fixed number of messages and HSS stacks trees for more.
Low-S normalization: The rule that an ECDSA signature's s value must lie in the lower half of the range (s ≤ n/2), adopted by Bitcoin and Ethereum to remove ECDSA's built-in signature malleability.

M

MD5: Ron Rivest's 128-bit hash function from 1991 (RFC 1321), broken for collisions since 2004 and for chosen-prefix collisions since 2007, and unsafe for any security use where an attacker can influence the input.
mDL (mobile driving licence): A driving licence or state ID held on a phone as an ISO/IEC 18013-5 mdoc, presented in person over NFC or Bluetooth or online, with each data element revealed separately and signed by the issuing authority.
mdoc (ISO/IEC 18013-5 mobile document): The CBOR-based credential format of ISO/IEC 18013-5, created for mobile driving licences, in which an issuer signs per-element digests in a mobile security object and the device proves possession with its own key.
Merkle tree: A binary hash tree in which each internal node hashes its two children, so one root hash commits to all leaves and membership or append-only growth can be proven with logarithmic-size proofs.
Merkle Tree Certificates (MTC): A certificate design in IETF standardization in which a CA logs each issuance into a Merkle tree and clients check a short inclusion proof instead of large post-quantum signatures.
ML-DSA (FIPS 204): The Module-Lattice-Based Digital Signature Algorithm of FIPS 204 (August 2024), derived from CRYSTALS-Dilithium, NIST's primary post-quantum signature with parameter sets ML-DSA-44, ML-DSA-65 and ML-DSA-87.
ML-KEM (FIPS 203): The Module-Lattice-Based Key-Encapsulation Mechanism of FIPS 203 (August 2024), derived from CRYSTALS-Kyber, the standard post-quantum key exchange with parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024.
mlkem768x25519-sha256: The SSH hybrid key exchange combining ML-KEM-768 with X25519 and SHA-256, standardized in RFC 10042 and the OpenSSH default since version 10.0 (April 2025).
MTA-STS (SMTP MTA Strict Transport Security): The mechanism of RFC 8461 by which a mail domain publishes a policy over HTTPS requiring senders to deliver only over TLS with a valid certificate to listed MX hosts.
mTLS (mutual TLS): TLS in which the client also authenticates with a certificate and a CertificateVerify signature, so both ends prove possession of private keys; common for service-to-service traffic, devices and OAuth sender-constrained tokens.
MuSig2: The two-round multi-signature scheme of BIP-327 in which n signers jointly produce one BIP-340 Schnorr signature valid under a single aggregate public key, indistinguishable on-chain from a single-signer spend.

N

Name constraints: The X.509 extension (OID 2.5.29.30), allowed only in CA certificates, that limits the names subordinate certificates may contain through permitted and excluded subtrees of DNS names, IP ranges, e-mail domains and directory names.
NIST IR 8547: NIST's "Transition to Post-Quantum Cryptography Standards", an initial public draft from November 2024, which proposes deprecating 112-bit quantum-vulnerable algorithms after 2030 and disallowing all of them after 2035.
NIST post-quantum security category: One of five strength levels NIST defines for post-quantum parameter sets by comparison with breaking AES or SHA-2/SHA-3: category 1 ≈ AES-128 key search, 3 ≈ AES-192, 5 ≈ AES-256, with 2 and 4 pegged to SHA-256 and SHA3-384 collisions.
Nonce (ECDSA k): A number used only once; in ECDSA, DSA and Schnorr signatures it is the per-signature secret k, which must also be unpredictable and uniformly distributed.
Nostr: A decentralized social and messaging protocol in which users are secp256k1 key pairs and every event is a JSON object identified by its SHA-256 hash and signed with a BIP-340 Schnorr signature.
npm provenance: Signed SLSA provenance attached to npm packages published from supported CI (generally available since 26 September 2023), which links each package version to its source repository, commit and build workflow.

O

OAuth 2.0: The authorization framework of RFC 6749 (2012) in which an authorization server issues access tokens to clients so they can call APIs with delegated, scoped permissions instead of user passwords.
OCSP (Online Certificate Status Protocol): The protocol of RFC 6960 in which a client asks a CA's responder whether a specific certificate is revoked and receives a signed good, revoked or unknown answer with a validity window.
OCSP stapling: A TLS feature in which the server fetches a fresh OCSP response for its own certificate and sends it in the handshake, sparing clients a privacy-leaking lookup to the CA.
OID (object identifier): A globally unique dotted sequence of integers such as 1.2.840.10045.2.1, assigned through a delegated registration tree and used in ASN.1 to name algorithms, curves, extensions and policies.
OIDC (OpenID Connect): The identity layer on top of OAuth 2.0 (OpenID Connect Core 1.0, 2014) that lets a client verify who a user is through a signed ID token and obtain profile claims from a UserInfo endpoint.
OpenID4VP (OpenID for Verifiable Presentations): The OpenID Foundation protocol (Final 1.0, July 2025) by which a verifier requests credentials from a wallet and receives a presentation, built on OAuth 2.0 and used by the EU Digital Identity Wallet.
OpenPGP: The IETF standard for public-key encryption and signatures of messages and files with user-managed keys (RFC 9580, July 2024), implemented by GnuPG, Sequoia, OpenPGP.js and others.
OpenPGP v6 key: The key format introduced by RFC 9580, with 32-byte SHA-256 fingerprints, native Ed25519/X25519/Ed448/X448 algorithms and salted v6 signatures, replacing the SHA-1-based v4 keys of RFC 4880.
OpenSSH private key format: The openssh-key-v1 container written by ssh-keygen by default since OpenSSH 7.8 (2018), stored as -----BEGIN OPENSSH PRIVATE KEY----- and encrypted with a bcrypt-based KDF when a passphrase is set.
Organization validation (OV): The certificate validation level in which the CA verifies the legal existence, name and address of the applying organization in addition to domain control, and puts them in the certificate subject.

P

P-256 (secp256r1): The NIST elliptic curve over a 256-bit prime field, also named secp256r1 and prime256v1, that gives about 128-bit security and is the most widely deployed curve for ECDSA and ECDH.
P-384 (secp384r1): The NIST prime-field elliptic curve with a 384-bit order, giving about 192-bit security, required by the NSA's CNSA 1.0 suite and common in government and CA hierarchies.
P-521 (secp521r1): The largest NIST prime curve, defined over the Mersenne prime 2⁵²¹ − 1 and giving about 256-bit security; JOSE ES512 means ECDSA on P-521 with SHA-512, not a 512-bit curve.
PAdES: The ETSI profile of PDF signatures (EN 319 142) for advanced electronic signatures under eIDAS, with baseline levels B-B, B-T (timestamped), B-LT (validation data embedded) and B-LTA (archival timestamps).
PASETO (Platform-Agnostic Security Tokens): A token format designed as a simpler alternative to JOSE, with versioned protocols instead of negotiable algorithms: v4.public tokens are Ed25519-signed and v4.local tokens are encrypted with XChaCha20 and authenticated with keyed BLAKE2b.
Passkey: A FIDO2/WebAuthn discoverable credential — a key pair bound to one website or app, unlocked with the device's biometric, PIN or password — that replaces a password with a phishing-resistant signature.
Password: A secret string memorized by a user and checked by a server, the most common and most phishable authenticator, which NIST SP 800-63B-4 regulates by length, blocklists and storage rules rather than complexity.
Password hashing: Storing a password as the output of a deliberately slow, salted, preferably memory-hard function such as Argon2id, scrypt, bcrypt or PBKDF2, so that a stolen database resists offline guessing.
PDF signature: A digital signature embedded in a PDF file (ISO 32000-2) whose /ByteRange covers everything except the signature value, typically a detached CMS or CAdES signature with certificate chain and timestamp.
PEM: The text wrapping of DER data as base64 between -----BEGIN label----- and -----END label----- lines, standardized for PKIX objects in RFC 7468 and used by most tools to store certificates and keys.
permit (EIP-2612 and Permit2): Signature-based token approvals: an off-chain EIP-712 signature authorizes a spender to move tokens, replacing an on-chain approve transaction, either per token (EIP-2612) or through Uniswap's shared Permit2 contract.
personal_sign: The Ethereum JSON-RPC wallet method that signs a message with the EIP-191 version 0x45 prefix, returning a 65-byte r‖s‖v signature; the default for log-in and simple message signing.
Phishing resistance: The property of an authentication method that a look-alike site cannot capture and replay credentials, achieved when the authenticator binds its response cryptographically to the real origin, as WebAuthn and client-certificate TLS do.
PIV (Personal Identity Verification): The US federal smart-card standard (FIPS 201-3, 2022) and its card interface (SP 800-73), whose key slots 9A, 9C, 9D and 9E hold authentication, signature, key-management and card-authentication keys; YubiKeys and other tokens implement it.
PKCE (Proof Key for Code Exchange): The OAuth extension of RFC 7636 in which the client sends a hash of a random code_verifier with the authorization request and the verifier itself with the token request, so an intercepted authorization code is useless.
PKCS #1 key format: The RSA-only ASN.1 structures RSAPublicKey and RSAPrivateKey from RFC 8017 Appendix A, stored in PEM as -----BEGIN RSA PUBLIC KEY----- and -----BEGIN RSA PRIVATE KEY-----.
PKCS #8: The algorithm-agnostic private key container (PrivateKeyInfo, RFC 5208; OneAsymmetricKey, RFC 5958) stored in PEM as -----BEGIN PRIVATE KEY----- or, password-protected, -----BEGIN ENCRYPTED PRIVATE KEY-----.
PKCS #12 (PFX): The password-protected archive format of RFC 7292, usually saved as .p12 or .pfx, that bundles a private key with its certificate chain for import into browsers, Windows, macOS, Java and Android.
Point compression: Encoding an elliptic-curve point by its x-coordinate plus one bit of y instead of both coordinates, which roughly halves public key size at the cost of a square root when decoding.
Post-quantum cryptography (PQC): Public-key algorithms designed to stay secure against large quantum computers, such as ML-KEM, ML-DSA and SLH-DSA (FIPS 203–205, 2024), which replace RSA, Diffie–Hellman and elliptic-curve schemes.
Pre-hash signing (HashEdDSA, HashML-DSA): Signing a digest of the message rather than the message itself, either implicitly (ECDSA, RSA) or through explicitly separate, domain-separated variants such as Ed25519ph and HashML-DSA.
Private key: The secret half of an asymmetric key pair, used to sign, decrypt or agree on keys; anyone who holds it can act as its owner, so it must never leave its trust boundary unprotected.
PS256: The JWS algorithm RSASSA-PSS with SHA-256 and MGF1-SHA-256 (RFC 7518 §3.5), which uses the same RSA keys as RS256 with the randomized, provably secure PSS padding.
PSBT (partially signed Bitcoin transaction): The interchange format of BIP-174 (version 0) and BIP-370 (version 2) that carries an unsigned transaction plus all data signers need, so wallets, hardware devices and coordinators can sign in separate steps.
Public key: The half of an asymmetric key pair that can be shared freely and is used to verify signatures, encrypt to, or agree on keys with the holder of the matching private key.

Q

QUIC: The UDP-based transport protocol of RFC 9000 that integrates the TLS 1.3 handshake (RFC 9001), encrypts nearly all transport metadata and carries HTTP/3.

R

Raw r‖s signature format (IEEE P1363): The fixed-length encoding of an ECDSA or DSA signature as r and s concatenated, each left-padded to the byte length of the group order, used by JOSE, COSE, WebCrypto and many HSM APIs.
RFC 6979 (deterministic ECDSA): The 2013 specification by Thomas Pornin that derives the DSA or ECDSA nonce k from the private key and the message hash with HMAC-DRBG, so signing needs no random number generator.
Root CA (root certificate): A self-signed CA certificate that verifiers trust directly because it ships in their root store, serving as the anchor at which every certificate path must end.
Root store (trust store): The set of root CA certificates that an operating system, browser or runtime trusts as anchors for certificate path validation, curated by a root program with its own policy.
RS256: The JWS algorithm RSASSA-PKCS1-v1_5 with SHA-256 (RFC 7518 §3.3), the historical default of OpenID Connect providers, with signatures as long as the RSA modulus (256 bytes for 2048-bit keys).
RSA: The public-key cryptosystem of Rivest, Shamir and Adleman (1977), whose security rests on the difficulty of factoring a large modulus n = p·q and which is used for signatures and, historically, key transport.
RSA-OAEP: RSA encryption with Optimal Asymmetric Encryption Padding (RFC 8017 §7.1), used in JWE as RSA-OAEP (SHA-1) and RSA-OAEP-256 (SHA-256) to wrap content keys, replacing the attackable PKCS #1 v1.5 encryption.
RSASSA-PKCS1-v1_5: The deterministic RSA signature padding of PKCS #1 v1.5 (RFC 8017 §8.2) that wraps the hash in an ASN.1 DigestInfo padded with 0xFF bytes; it is JWT's RS256 and the most common RSA signature in X.509.
RSASSA-PSS: The randomized RSA signature scheme of PKCS #1 v2.1 and later (RFC 8017 §8.1) that encodes the hash with a random salt and the MGF1 mask function and has a tight security proof that PKCS #1 v1.5 lacks.

S

S/MIME: The standard for signing and encrypting e-mail with X.509 certificates and CMS (RFC 8551, S/MIME 4.0), built into Outlook, Apple Mail and Thunderbird and governed for public certificates by the CA/Browser Forum S/MIME Baseline Requirements.
Safe multisig (Safe smart account): The most widely used Ethereum smart-contract wallet, which executes a transaction only when a threshold of owners has signed its EIP-712 SafeTx hash; signatures can be ECDSA, contract signatures (ERC-1271) or on-chain approvals.
SAML 2.0: The OASIS XML standard (March 2005) for exchanging signed authentication and attribute assertions between an identity provider and service providers, still the backbone of enterprise single sign-on.
SBOM (software bill of materials): A machine-readable inventory of the components, versions, licenses and dependency relationships in a piece of software, expressed mainly in SPDX or CycloneDX, used for vulnerability management and compliance.
Schnorr signature: A discrete-logarithm signature scheme (Claus Schnorr, 1989) whose response s = r + e·x is linear in the key, enabling simple security proofs, batch verification and native multi-signatures.
SCT (signed certificate timestamp): A CT log's signed promise to include a certificate or precertificate in its public log, delivered to clients embedded in the certificate, in a TLS extension or in a stapled OCSP response.
SD-JWT (Selective Disclosure for JWTs): The format of RFC 9901 (November 2025) in which an issuer signs salted digests of claims, and the holder reveals only chosen claims by sending the matching disclosures, optionally with a key-binding JWT.
SD-JWT VC: The IETF Internet-Draft that profiles SD-JWT for verifiable digital credentials with typ dc+sd-jwt, a credential type claim vct, status and issuer key discovery; one of the two EU wallet credential formats.
SEC 1 ECPrivateKey: The elliptic-curve private key structure from SEC 1 and RFC 5915, written by OpenSSL as -----BEGIN EC PRIVATE KEY-----, that stores the scalar with optional curve parameters and public point.
secp256k1: The 256-bit Koblitz elliptic curve y² = x³ + 7 from SEC 2, chosen by Bitcoin and also used by Ethereum and Nostr, with about 128-bit security.
Secure Enclave: Apple's isolated security coprocessor in iPhone, iPad, Mac and Apple Watch chips, which creates non-exportable keys and signs or decrypts inside the chip, optionally gated by Face ID, Touch ID or the passcode.
Security level (bits of security): A measure of cryptographic strength in which s bits means the best known attack needs about 2ˢ operations, used to compare key sizes across algorithms such as AES-128, P-256 and RSA-3072.
security.txt: A text file served at /.well-known/security.txt (RFC 9116) that tells security researchers how to report vulnerabilities to a site's owner.
Self-signed certificate: A certificate whose issuer and subject are the same and whose signature was made with its own private key, so it is trusted only where it has been installed as a trust anchor.
SHA-1: The 160-bit hash function of FIPS 180-1 (1995), now broken for collisions in practice and being retired by NIST for all cryptographic protection by 31 December 2030.
SHA-2: The family of hash functions in FIPS 180-4 — SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 — designed by the NSA and published in 2001, today the default hashes almost everywhere.
SHA-3: The Keccak-based hash family standardized in FIPS 202 (2015) — SHA3-224, SHA3-256, SHA3-384, SHA3-512 and the SHAKE128 and SHAKE256 extendable-output functions — built on a sponge rather than Merkle–Damgård.
SHA-256: The 256-bit member of the SHA-2 family (FIPS 180-4), the default hash of TLS, JWT, X.509, Bitcoin and most file-integrity tools, with 128-bit collision and 256-bit preimage resistance.
SHAKE128 and SHAKE256: The extendable-output functions (XOFs) of FIPS 202 that produce output of any requested length from the Keccak sponge, with security of 128 and 256 bits respectively for long enough outputs.
Shamir secret sharing: Adi Shamir's 1979 scheme that splits a secret into n shares using a random polynomial so that any k of them reconstruct it and any k − 1 reveal nothing at all.
Shor's algorithm: Peter Shor's 1994 quantum algorithm that factors integers and computes discrete logarithms in polynomial time, which on a large fault-tolerant quantum computer would break RSA, Diffie–Hellman, ECDSA, EdDSA and ECDH.
Short-lived certificate: A certificate whose validity is so short — at most 7 days for public TLS certificates issued since 15 March 2026 — that it simply expires instead of relying on revocation checks.
Side-channel attack: An attack that learns secrets from how a computation behaves physically or temporally — its timing, cache accesses, power draw, electromagnetic emissions or reaction to induced faults — rather than from its inputs and outputs.
SIGHASH flags: The byte appended to a Bitcoin signature that selects which parts of the transaction it covers: ALL (0x01), NONE (0x02), SINGLE (0x03), optionally combined with ANYONECANPAY (0x80), plus the Taproot default 0x00.
Signature malleability: The property of a signature scheme or its encoding that lets anyone turn a valid signature into a different valid signature for the same message and key without knowing the private key.
Signature verification: The public-key check that a signature was produced over exactly this message by the private key matching a given public key, using an algorithm the verifier chose in advance.
signature_algorithms extension: The TLS extension (13) in which a client or server lists the signature schemes it accepts, such as ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256 and ed25519, with signature_algorithms_cert (50) covering certificate signatures separately.
Sigstore: An open-source signing service that certifies ephemeral keys for OIDC identities (Fulcio) and logs signatures publicly (Rekor), so artifacts can be signed and verified without long-term keys.
SIWE (Sign-In with Ethereum): The ERC-4361 message format for logging in with an Ethereum account: a human-readable text with domain, address, URI, version, chain ID, nonce and issue time, signed with personal_sign.
SLH-DSA (FIPS 205): The Stateless Hash-Based Digital Signature Algorithm of FIPS 205 (August 2024), derived from SPHINCS+, whose security rests only on hash functions, at the cost of signatures of 7.8–50 KB and slow signing.
SLSA (Supply-chain Levels for Software Artifacts): An OpenSSF framework of incremental levels for build and source integrity — for example, Build L3 means provenance generated by a hardened, isolated build platform — with v1.2 (November 2025) as the current specification.
SNI (Server Name Indication): The TLS extension (RFC 6066 §3, extension 0) in which the client names the host it wants, so one IP address can serve many certificates; it is sent in clear text unless Encrypted Client Hello is used.
sntrup761x25519-sha512: The SSH key exchange that combines Streamlined NTRU Prime sntrup761 with X25519 and hashes with SHA-512, OpenSSH's default from version 9.0 (2022) until mlkem768x25519-sha256 replaced it in 10.0.
SPF (Sender Policy Framework): The DNS-published policy of RFC 7208 listing which hosts may send mail using a domain in the SMTP envelope (MAIL FROM or HELO), checked by receivers against the connecting IP address.
SPF 10-lookup limit: The RFC 7208 rule that evaluating an SPF record may trigger at most 10 DNS-querying mechanisms and modifiers (include, a, mx, ptr, exists, redirect), beyond which the result is permerror.
SSH (Secure Shell): The protocol of RFC 4251–4254 for authenticated, encrypted remote login, command execution, file transfer and port forwarding, in which the server proves itself with a host key and users authenticate with keys, certificates or passwords.
SSH certificate: An OpenSSH-specific signed statement (not X.509) in which a certificate authority key binds a user or host public key to principals, a validity window and options, removing the need to distribute individual keys.
SSH host key: The long-term key pair with which an SSH server signs each key exchange, proving its identity to clients that have recorded the public key in known_hosts or trust a CA that certified it.
SSHSIG (SSH signatures): OpenSSH's format for signing arbitrary data with SSH keys (ssh-keygen -Y sign), which binds a namespace to each signature and underlies SSH-signed Git commits and allowed-signers verification.
STARTTLS: A protocol command that upgrades an existing plaintext connection to TLS — in SMTP (RFC 3207), IMAP, POP3, LDAP and XMPP — and that is open to downgrade unless a policy requires TLS.
Subject alternative name (SAN): The X.509 extension (OID 2.5.29.17) that lists the DNS names, IP addresses, e-mail addresses or URIs a certificate is valid for, and the only field browsers use to match a server's host name.
SubjectPublicKeyInfo (SPKI): The ASN.1 structure from RFC 5280 that pairs an algorithm identifier with the public key bits, used inside every X.509 certificate and as the standard public key file format (-----BEGIN PUBLIC KEY-----).

T

Taproot: The Bitcoin soft fork of BIPs 340, 341 and 342, activated at block 709,632 on 14 November 2021, that added Schnorr signatures and P2TR outputs committing to a key and an optional tree of scripts.
Threshold signatures: Schemes in which a private key is split among n parties so that any t of them can jointly produce one ordinary-looking signature while any smaller group learns nothing about the key.
TLS (Transport Layer Security): The IETF protocol that authenticates a server (and optionally a client) and encrypts a byte stream between them, used by HTTPS, mail, APIs and most other Internet protocols; current version 1.3.
TLS 1.2: The 2008 version of TLS (RFC 5246), still widely supported, that introduced AEAD cipher suites and SHA-256 but needs two round trips and permits weak options that TLS 1.3 removed.
TLS 1.3: The current version of TLS, published as RFC 8446 in 2018 and revised as RFC 9846 in 2026, with a one-round-trip handshake, mandatory forward secrecy, AEAD-only cipher suites and an encrypted handshake.
TLS certificate compression: The TLS 1.3 extension of RFC 8879 (compress_certificate, 27) that lets the server compress its certificate chain with zlib, brotli or zstd, typically shrinking it by a third or more.
TLS handshake: The opening exchange of a TLS connection in which client and server agree on parameters, perform a key exchange, authenticate (usually the server via its certificate) and derive the traffic keys.
TLS session resumption: Re-establishing a TLS session from secrets of an earlier connection, which skips certificate authentication and saves computation and, in TLS 1.3, can carry 0-RTT data.
Trusted publishing: Publishing packages to a registry from CI with a short-lived OIDC-based credential instead of a long-lived API token, introduced by PyPI in April 2023 and offered by npm (generally available July 2025), RubyGems, crates.io and others.
Trusted timestamping (RFC 3161): Obtaining a signed token from a time-stamping authority that binds a hash of data to a trusted time, so a signature can be shown to predate a certificate's expiry or revocation.
TUF (The Update Framework): A specification for secure software updates, CNCF-graduated in 2019, that separates signing into root, targets, snapshot and timestamp roles with thresholds and expiry to survive key compromise.
typ (JOSE type header): The JOSE header parameter that declares the media type of the whole token, such as JWT, at+jwt, dpop+jwt or kb+jwt, used for explicit typing so one kind of token cannot be substituted for another.

U

User verification (UV): The authenticator's local check that the authorized user is present and identified — by biometric, PIN or device password — signaled by the UV flag in WebAuthn authenticator data.

V

Verifiable credential: A tamper-evident set of claims about a subject, signed by an issuer and held by the subject in a wallet, which a verifier can check without contacting the issuer; standardized in several formats (W3C VC, SD-JWT VC, mdoc).
VMC (Verified Mark Certificate): An X.509 certificate that binds a domain to a registered trademark logo for BIMI, issued after trademark and identity validation and carrying the SVG logo in a logotype extension.

W

Weak key: A key that is easier to break than its nominal size suggests, because of a flawed generator, too little entropy, a structural defect or reuse across devices.
Web Bot Auth: An IETF effort, based on HTTP Message Signatures, for automated clients such as crawlers and AI agents to sign their requests with a published key so websites can identify them reliably instead of trusting user-agent strings or IP ranges.
Web of trust: OpenPGP's decentralized trust model in which users certify each other's keys and each user decides how much to trust certifiers, instead of relying on certificate authorities.
WebAuthn (Web Authentication): The W3C browser API (navigator.credentials.create and get with publicKey options) through which websites register and use public-key credentials on authenticators; Level 3 became a W3C Recommendation on 25 August 2026.
Wildcard certificate: A certificate with a subject alternative name such as *.example.com that matches any single label in that position, for example www.example.com but neither example.com nor a.b.example.com.
WKD (Web Key Directory): A way to publish OpenPGP keys on your own domain under /.well-known/openpgpkey/, so mail clients can fetch the key for an e-mail address over HTTPS (draft-koch-openpgp-webkey-service).

X

X.509: The ITU-T certificate format, profiled for the Internet by RFC 5280, that binds a public key to a subject name and extensions under the signature of an issuing certificate authority.
x5c (X.509 certificate chain header): The JOSE header and JWK member that carries an X.509 certificate chain as an array of base64-encoded (not base64url) DER certificates, the first containing the signing key.
X25519: The Diffie–Hellman function on Curve25519 defined in RFC 7748, with 32-byte keys and a 32-byte shared secret, used for key exchange in TLS 1.3, SSH, WireGuard, Signal and age.
X25519MLKEM768: The TLS 1.3 hybrid key-exchange group 0x11EC (RFC 10024) that combines ML-KEM-768 with X25519, the post-quantum default in current browsers, OpenSSL and Go.
XAdES: The ETSI format for advanced electronic signatures on XML (EN 319 132), which extends XML-DSig with signed properties such as signing time and certificate digest and with B-T, B-LT and B-LTA long-term levels.
XML Signature (XML-DSig): The W3C standard for signing XML (XML Signature Syntax and Processing 1.1, 2013), in which a ds:Signature element references the signed data by URI, canonicalizes it and signs a SignedInfo block of digests.
XML signature wrapping (XSW): A class of attacks on XML-signed messages in which an attacker moves the signed element and inserts a forged one, so the signature still verifies over the original while the application processes the forgery.
XMSS and XMSS^MT: The eXtended Merkle Signature Scheme of RFC 8391 and NIST SP 800-208, a stateful hash-based signature built on WOTS+ one-time keys, with a multi-tree variant for larger signing capacity.
xpub (extended public key): A BIP-32 extended public key — public key plus chain code — that can derive every non-hardened child public key and address below it, used by watch-only wallets and payment servers.

#

0-RTT (TLS early data): The TLS 1.3 feature that lets a resuming client send application data in its first flight, encrypted with a key from a previous session, at the cost of replay protection and forward secrecy for that data.

Glossary

A to Z

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

#

By topic

Signatures · 52 terms

JOSE and JWT · 39 terms

PKI and certificates · 69 terms

TLS · 65 terms

Email · 18 terms

Web3 · 33 terms

Post-quantum · 34 terms

Identity and WebAuthn · 53 terms

Supply chain · 30 terms

OpenPGP · 9 terms

Mathematics · 48 terms