Referenz

Glossar

302 Begriffe zu digitalen Signaturen, Zertifikaten, Tokens, Protokollen und Post-Quanten-Kryptografie, jeder in wenigen Sätzen definiert und mit den Standards verknüpft, die ihn festlegen.

302 von 302 angezeigt

A bis Z

A

AAGUID (Authenticator Attestation GUID): Die 16-Byte-Kennung in den attestierten Credential-Daten von WebAuthn, die das Modell des Authenticators benennt, etwa einen bestimmten Sicherheitsschlüssel oder Passwortmanager; über sie werden Metadaten und Symbole nachgeschlagen.
Abgetrennte Signatur (Detached Signature): Eine Signatur, die getrennt von den signierten Daten gespeichert wird – etwa eine OpenPGP-Datei mit der Endung .sig oder .asc, eine SSHSIG-Datei oder eine CMS-Signatur ohne eingekapselten Inhalt –, sodass die Originaldatei unverändert bleibt.
Access Token: Das Credential, das ein OAuth-Client einem Ressourcenserver vorlegt, um im Namen eines Benutzers oder im eigenen Namen eine API aufzurufen: entweder ein opaker String, der per Introspection geprüft wird, oder ein in sich geschlossenes JWT.
ACME (automatisierte Zertifikatsverwaltung): Das für Let's Encrypt entwickelte Protokoll aus RFC 8555, mit dem ein Client über Challenges nachweist, dass er über die Identifier verfügt, und ohne menschliches Zutun Zertifikate von einer CA erhält.
ACME Renewal Information (ARI): Die ACME-Erweiterung aus RFC 9773 (Juni 2025), über die eine CA den Clients das Zeitfenster mitteilt, in dem jedes Zertifikat erneuert werden sollte – so kann die CA die Last verteilen und vor Massenwiderrufen eine vorzeitige Erneuerung anfordern.
ACME-Challenge dns-01: Die ACME-Methode zur Domain-Validierung, bei der der Client einen TXT-Eintrag unter _acme-challenge.domain mit dem Wert base64url(SHA-256(Schlüsselautorisierung)) veröffentlicht; als einzige ACME-Methode kann sie Wildcard-Namen validieren.
ACME-Challenge http-01: Die ACME-Methode zur Domain-Validierung, bei der der Client die Schlüsselautorisierung unter http://domain/.well-known/acme-challenge/token auf Port 80 bereitstellt und die CA sie aus mehreren Netzwerkperspektiven abruft.
AEAD (authentifizierte Verschlüsselung): Ein symmetrischer Verschlüsselungsmodus, der Vertraulichkeit und Integrität in einer Operation liefert und zusätzlich unverschlüsselte zugehörige Daten wie Header authentifiziert; generisch definiert in RFC 5116.
AES-GCM: AES im Galois/Counter Mode (NIST SP 800-38D), das am weitesten verbreitete AEAD: Verschlüsselung im Counter-Modus plus ein GHASH-Authentifikator, normalerweise mit einer 96-Bit-Nonce und einem 128-Bit-Tag.
age (Dateiverschlüsselung): Ein kleines, modernes Tool und Format zur Dateiverschlüsselung (age-encryption.org/v1) von Filippo Valsorda, das für X25519-, SSH- oder hybride Post-Quanten-Empfänger oder mit einer Passphrase verschlüsselt – ohne Signaturen und ohne Konfiguration.
alg (JOSE-Header für den Algorithmus): Der JOSE-Header-Parameter, der den Signatur- oder MAC-Algorithmus eines JWS (etwa ES256) oder den Algorithmus für das Schlüsselmanagement eines JWE (etwa RSA-OAEP-256) nennt; registriert durch RFC 7518 und spätere RFCs.
alg none (ungesichertes JWS): Der JWS-Algorithmuswert none (RFC 7518 §3.6) für ein unsigniertes Token mit leerem Signaturteil, das ein Verifizierer nie akzeptieren darf, es sei denn, er erwartet ausdrücklich ungesicherten Inhalt.
Algorithm Confusion (Schlüsselverwechslung): Eine Schwachstelle der Prüfung, bei der eine Bibliothek den Header alg des Tokens den Algorithmus wählen lässt, sodass ein Schlüssel, der für einen Algorithmus gedacht ist, mit einem anderen verwendet wird – klassisch ein öffentlicher RSA-Schlüssel als HS256-Secret.
ALPN (Application-Layer Protocol Negotiation): Die TLS-Erweiterung aus RFC 7301, mit der der Client Anwendungsprotokolle wie h2 und http/1.1 anbietet und der Server im Handshake eines davon auswählt – ohne zusätzlichen Roundtrip.
Anforderungen an Massenabsender: Regeln, die Gmail und Yahoo (ab Februar 2024) sowie Microsoft (ab Mai 2025) für Absender von mehr als etwa 5.000 Nachrichten pro Tag durchsetzen: SPF, DKIM, ein DMARC-Eintrag mit Alignment und Ein-Klick-Abmeldung.
APK-Signaturverfahren (v1–v4): Die Formate zum Signieren von Android-Apps: v1-JAR-Signatur, v2 (Android 7.0) und v3 (Android 9, Schlüsselrotation) als Signaturen über die ganze Datei im APK-Signaturblock, v3.1 (Android 13) für gezielte Rotation und v4 (Android 11) für inkrementelle Installationen.
Apple-Notarisierung: Die automatisierte Malware-Prüfung von Apple für Mac-Software, die mit Developer ID signiert ist: Builds werden mit notarytool hochgeladen, Apple liefert ein Ticket zurück, das Gatekeeper prüft, und das Ticket lässt sich an die App oder das Installationspaket anheften (Stapling).
ARC (Authenticated Received Chain): Das experimentelle Protokoll aus RFC 8617 (2019), bei dem jede Zwischenstation, die eine Nachricht verarbeitet, die gesehenen Authentifizierungsergebnisse festhält und versiegelt, damit der endgültige Empfänger Ergebnissen vertrauen kann, die durch Weiterleitung oder Mailinglisten später ungültig wurden.
ASCII-Armor: Die Textkodierung von OpenPGP für binäre Pakete: base64 zwischen Zeilen wie -----BEGIN PGP PUBLIC KEY BLOCK----- und -----END PGP PUBLIC KEY BLOCK----- (RFC 9580 §6.2).
ASN.1 (Abstract Syntax Notation One): Die Sprache aus ITU-T X.680 zur Beschreibung von Datenstrukturen unabhängig von ihrer Kodierung; mit ihr sind X.509-Zertifikate, CMS, Schlüssel im Format PKCS #8, OCSP, LDAP und Telekommunikationsprotokolle definiert.
Attestierung (WebAuthn): Eine bei der Registrierung mit dem Attestierungsschlüssel des Authenticators signierte Aussage, die der Relying Party mitteilt, welche Art von Authenticator ein Credential erzeugt hat, damit sie Geräterichtlinien durchsetzen kann.
aud (Audience-Claim): Der registrierte JWT-Claim (RFC 7519 §4.1.3), der die vorgesehenen Empfänger eines Tokens nennt, als String oder Array von Strings; jeder Empfänger muss prüfen, dass seine eigene Kennung darin enthalten ist.
Authenticator (FIDO/WebAuthn): Die Komponente, die WebAuthn-Credentials verwahrt und Signaturen erzeugt – ein im Gerät eingebauter Plattform-Authenticator, ein portabler Sicherheitsschlüssel oder ein Credential-Manager, der Passkeys synchronisiert.
Authenticator-Daten: Die binäre Struktur, die jede WebAuthn-Antwort enthält: ein 32-Byte-SHA-256-Hash der RP-ID, ein Flags-Byte, ein 4-Byte-Signaturzähler und optional attestierte Credential-Daten sowie CBOR-Ausgaben von Erweiterungen.
Authenticode: Das Codesignaturformat von Microsoft für ausführbare Windows-Dateien, Treiber, Installer und Skripte: eine SignedData-Struktur nach PKCS #7 über einen Hash der Datei, eingebettet in die Zertifikatstabelle der PE-Datei und meist mit einem Zeitstempel versehen.

B

Base64url: Das URL- und dateinamensichere base64-Alphabet aus RFC 4648 §5, das + und / durch - und _ ersetzt und in JOSE das Padding mit = weglässt; jeder Teil eines JWT ist base64url-kodiert.
Baseline Requirements (Basisanforderungen, BR): Die Regeln des CA/Browser Forums für die Ausstellung und Verwaltung öffentlich vertrauenswürdiger TLS-Serverzertifikate; sie decken Validierungsmethoden, Zertifikatsprofile, Laufzeiten, Widerruf und den Betrieb von CAs ab.
Basic Constraints: Die X.509-Erweiterung (OID 2.5.29.19), deren Flag cA angibt, ob ein Zertifikat zu einer CA gehört, die andere Zertifikate signieren darf, mit einem optionalen pathLenConstraint, der begrenzt, wie viele CAs in der Kette darunter folgen dürfen.
Bearer Token: Ein Access Token, das jedem Zugriff gewährt, der es vorlegt, ohne Proof of Possession für einen Schlüssel (RFC 6750); meist wird es als Authorization: Bearer mit anschließendem Token gesendet.
Benutzerverifizierung (UV): Die lokale Prüfung durch den Authenticator, dass der berechtigte Benutzer anwesend und identifiziert ist – per Biometrie, PIN oder Gerätepasswort –, signalisiert durch das UV-Flag in den Authenticator-Daten von WebAuthn.
BIMI (Markenlogos in E-Mails): Ein Verfahren aus DNS-Eintrag und Zertifikat, noch ein IETF-Internet-Draft, mit dem eine Domain mit durchgesetztem DMARC ihr Logo neben Nachrichten anzeigen lässt, in Postfächern unterstützender Anbieter wie Gmail, Yahoo und Apple Mail.
BIP-32 (hierarchisch-deterministische Wallets): Der Bitcoin-Standard, der mit HMAC-SHA512 und Chain Codes einen Baum von Schlüsseln aus einem einzigen Seed ableitet, sodass ein Backup alle Adressen abdeckt und erweiterte öffentliche Schlüssel Empfangsadressen ohne private Schlüssel ableiten können.
BIP-39 (mnemonische Seed-Phrasen): Der Standard, der die Entropie einer Wallet als 12–24 Wörter aus einer Liste von 2.048 Wörtern kodiert und die Phrase mit PBKDF2-HMAC-SHA512 (2.048 Iterationen) zum 64-Byte-Seed streckt, den BIP-32 verwendet.
BIP-137 (Format signierter Nachrichten): Das Bitcoin-Format zum Signieren von Nachrichten mit einer wiederherstellbaren ECDSA-Signatur aus 65 Byte, deren Header-Byte sowohl die Recovery-ID als auch den Adresstyp kodiert: 27–30 P2PKH unkomprimiert, 31–34 komprimiert, 35–38 P2SH-P2WPKH, 39–42 P2WPKH.
BIP-322 (generische Nachrichtensignatur): Der Bitcoin-Standard zum Signieren von Nachrichten, der die Verfügung über eine Adresse beliebigen Typs nachweist, einschließlich SegWit, Taproot und Multisig, indem eine virtuelle Transaktion signiert wird, die von dieser Adresse ausgibt.
BIP-340 (Schnorr-Signaturen für secp256k1): Der Bitcoin-Standard für 64-Byte-Schnorr-Signaturen über secp256k1 mit öffentlichen Schlüsseln (32 Byte, nur x) und Tagged Hashes, genutzt in Taproot und Nostr.
Bitcoin-Adresse: Eine menschenlesbare Kodierung eines Bitcoin-Output-Skripts: die Legacy-Formate P2PKH (1…) und P2SH (3…) in Base58Check, SegWit v0 (bc1q…) in bech32 und Taproot (bc1p…) in bech32m.
BLAKE2: Eine schnelle Familie von Hashfunktionen (BLAKE2b für 64-Bit-Plattformen mit Digests bis 64 Byte, BLAKE2s für 32-Bit-Plattformen mit bis zu 32 Byte), spezifiziert in RFC 7693 und eingesetzt in Argon2, WireGuard, PASETO und libsodium.
Blind Signing (blindes Signieren): Das Genehmigen einer Transaktion oder Nachricht, deren Bedeutung das signierende Gerät nicht anzeigen kann – es zeigt meist nur einen Hash oder rohe Calldata –, sodass der Signierer dem möglicherweise kompromittierten Computer vertrauen muss, der sie vorbereitet hat.
BLS-Signaturen: Pairing-basierte Signaturen (Boneh, Lynn und Shacham, 2001), die kurz, deterministisch und nativ aggregierbar sind; am bekanntesten ist ihr Einsatz im Proof-of-Stake-Konsens von Ethereum auf der Kurve BLS12-381.
Brainpool-Kurven: Eine Familie elliptischer Kurven mit nachprüfbar pseudozufälligen Parametern (RFC 5639, 2010), die deutsche und andere europäische Behördenprofile als Alternative zu den NIST-Kurven bevorzugen.
Build-Provenance: Ein signierter, prüfbarer Nachweis darüber, wie ein Artefakt erzeugt wurde – Quell-Repository und Commit, Build-Plattform, Workflow und Eingaben –, anhand dessen Nutzer prüfen können, ob ein Paket aus der erwarteten Quelle und Pipeline stammt.

C

C2PA (Content Credentials): Der Standard der Coalition for Content Provenance and Authenticity für signierte Provenance-Manifeste, die in Bilder, Videos, Audio und Dokumente eingebettet werden und festhalten, wer Inhalte erstellt oder bearbeitet hat und mit welchen Tools, einschließlich KI-Generierung.
CA (Zertifizierungsstelle): Eine Organisation oder ein Dienst, der Zertifikate ausstellt und signiert, nach Prüfung, ob der Antragsteller über Namen oder Identität im Zertifikat verfügt.
CA/Browser Forum: Der freiwillige Zusammenschluss von Zertifizierungsstellen sowie Browser- und Betriebssystemherstellern, der die Baseline Requirements und weitere Regeln für öffentlich vertrauenswürdige TLS-, S/MIME- und Codesignatur-Zertifikate festlegt.
CAA (Certification Authority Authorization): Ein DNS-Eintragstyp (RFC 8659), in dem der Inhaber einer Domain die CAs auflistet, die für ihre Namen Zertifikate ausstellen dürfen; jede öffentliche CA muss diesen Eintrag vor der Ausstellung prüfen.
CBOM (kryptografische Stückliste): Ein maschinenlesbares Inventar der kryptografischen Bestandteile eines Systems – Algorithmen, Schlüssel, Zertifikate, Protokolle und Bibliotheken samt ihren Parametern –, mit dem sich Migrationen wie der Umstieg auf Post-Quanten-Kryptografie planen und verfolgen lassen.
Certificate Transparency (CT): Das System öffentlicher Append-only-Logs auf Basis von Merkle-Trees (RFC 6962), bei denen CAs jedes öffentlich vertrauenswürdige TLS-Zertifikat einreichen, damit Domaininhaber und Monitoring-Dienste fehlerhaft ausgestellte Zertifikate erkennen.
ChaCha20-Poly1305: Das AEAD, das die Stromchiffre ChaCha20 mit dem Authentifikator Poly1305 kombiniert (RFC 8439): 256-Bit-Schlüssel, 96-Bit-Nonces und 128-Bit-Tags, schnell in Software ohne AES-Hardware.
Cipher Suite: Eine benannte Kombination kryptografischer Algorithmen, die eine TLS-Verbindung verwendet; in TLS 1.3 bezeichnet sie nur das AEAD und den Handshake-Hash (zum Beispiel TLS_AES_128_GCM_SHA256), während die Namen unter TLS 1.2 auch Schlüsselaustausch und Authentifizierung festlegten.
ClientHello: Die erste Nachricht des TLS-Handshakes, im Klartext gesendet, in der der Client die unterstützten Versionen, Cipher Suites, Gruppen, Signaturalgorithmen, Key Shares und Erweiterungen wie den Servernamen auflistet.
CMS (Cryptographic Message Syntax): Der IETF-Nachfolger von PKCS #7 (RFC 5652) für signierte, für Empfänger verschlüsselte und authentifizierte Daten, genutzt von S/MIME, Authenticode, PDF-Signaturen, Zeitstempeln nach RFC 3161 und vielen Firmware-Formaten.
CNSA 2.0: Die Commercial National Security Algorithm Suite 2.0 der NSA (September 2022), die bis 2030–2035 ML-KEM-1024, ML-DSA-87, LMS oder XMSS, AES-256 sowie SHA-384 oder SHA-512 in nationalen Sicherheitssystemen der USA vorschreibt.
Codesignatur (Code Signing): Das Signieren von ausführbaren Dateien, Paketen, Skripten oder Firmware, damit Betriebssysteme, Stores und Nutzer den Herausgeber prüfen und Manipulationen erkennen können – mit X.509-Zertifikaten, Plattformschlüsseln, OpenPGP oder Sigstore.
Composite-Signaturen: Signaturen, die einen Post-Quanten- und einen klassischen Algorithmus unter einem Schlüssel und einer Algorithmuskennung kombinieren – zum Beispiel ML-DSA-65 mit ECDSA P-256 –, sodass eine Signatur die Prüfung nur besteht, wenn beide Komponenten sie bestehen.
COSE (CBOR Object Signing and Encryption): Das CBOR-Gegenstück zu JOSE (RFC 9052, RFC 9053) für Signaturen, MACs, Verschlüsselung und Schlüssel; genutzt von WebAuthn, mdoc-Führerscheinen, CWTs und C2PA.
cosign: Das Befehlszeilentool von Sigstore zum Signieren und Prüfen von Container-Images, Blobs und Attestierungen, entweder mit Schlüsseln oder schlüssellos mit OIDC-Identitäten und kurzlebigen Zertifikaten.
CRL (Zertifikatssperrliste): Eine von einer CA signierte und regelmäßig veröffentlichte Liste der Seriennummern widerrufener Zertifikate (RFC 5280 §5); Verifizierer laden sie herunter, um den Widerruf zu prüfen, ohne die CA für jedes Zertifikat einzeln abzufragen.
CRLite: Der Widerrufsmechanismus von Firefox, der den Widerrufsstatus jedes in Certificate Transparency protokollierten Zertifikats in kompakte Filter verdichtet, die der Browser herunterlädt und lokal abfragt.
CSPRNG (kryptografischer Zufallsgenerator): Ein Zufallszahlengenerator, dessen Ausgabe selbst ein Angreifer, der frühere Ausgaben gesehen hat, weder vorhersagen noch von echtem Zufall unterscheiden kann; nötig für Schlüssel, Nonces, Salts und Tokens.
CSR (Certificate Signing Request): Eine Nachricht im Format PKCS #10 (RFC 2986) mit einem Subject-Namen, einem öffentlichen Schlüssel und angeforderten Attributen, die mit dem passenden privaten Schlüssel signiert ist, um dessen Besitz nachzuweisen, und aus der eine CA ein Zertifikat erstellt.
CTAP (Client to Authenticator Protocol): Das Protokoll der FIDO Alliance zwischen einem Client (Browser oder Betriebssystem) und einem externen Authenticator über USB HID, NFC, Bluetooth oder den hybriden Transport per Smartphone, mit CBOR-kodierten Befehlen wie authenticatorMakeCredential.
Curve25519: Die Montgomery-Kurve y² = x³ + 486662x² + x über der Primzahl 2²⁵⁵ − 19, die Daniel J. Bernstein 2005 vorgestellt hat; Grundlage des Schlüsselaustauschs X25519 und, in Edwards-Form, der Signaturen mit Ed25519.
CWT (CBOR Web Token): Das CBOR-Gegenstück zu JWT (RFC 8392): ein Claim-Set als CBOR-Map mit ganzzahligen Claim-Schlüsseln, geschützt per COSE-Signatur, MAC oder Verschlüsselung.

D

DANE (DNS-basierte Authentifizierung): Der Einsatz von DNSSEC-signierten TLSA-Einträgen (RFC 6698, RFC 7671), um festzulegen, welches Zertifikat oder welchen öffentlichen Schlüssel ein TLS-Dienst vorlegen muss, entweder zusätzlich zu öffentlichen CAs oder an ihrer Stelle.
DER (Distinguished Encoding Rules): Die kanonische binäre Kodierung von ASN.1 aus ITU-T X.690, die jedem Wert genau eine Bytedarstellung gibt; deshalb sind Zertifikate, CSRs, CRLs, Schlüssel und viele Signaturen DER-kodiert.
DID (Decentralized Identifier): Eine URI der Form did:method:identifier (W3C DID Core 1.0, 2022), die zu einem DID-Dokument mit öffentlichen Schlüsseln und Service-Endpunkten aufgelöst wird; über sie verfügt ihr Subject und keine zentrale Registry.
Digest (Message Digest): Die Ausgabe fester Länge einer kryptografischen Hashfunktion über Daten, genutzt als kompakter, kollisionsresistenter Bezeichner dieser Daten und als die Eingabe, die die meisten Signaturverfahren tatsächlich signieren.
Digitale Signatur: Ein Wert, der mit einem privaten Schlüssel aus einer Nachricht berechnet wird und den jeder mit dem passenden öffentlichen Schlüssel prüfen kann; er belegt, dass die Nachricht unverändert ist und vom Inhaber des Schlüssels signiert wurde.
Discoverable Credential (Resident Key): Ein WebAuthn-Credential, dessen privaten Schlüssel und User Handle der Authenticator speichert, sodass es sich finden lässt, ohne dass der Server zuerst eine Credential-ID sendet; das ermöglicht die Anmeldung per Passkey ohne Benutzernamen.
Distinguished Name (DN): Der hierarchische X.500-Name für Subject und Aussteller eines Zertifikats, aufgebaut aus Attribut-Wert-Paaren wie CN, O, OU, L, ST und C.
DKIM (DomainKeys Identified Mail): Der E-Mail-Authentifizierungsstandard aus RFC 6376, bei dem die sendende Domain ausgewählte Header und den Body einer Nachricht signiert und den öffentlichen Schlüssel im DNS veröffentlicht, sodass Empfänger prüfen können, dass die Nachricht unverändert von dieser Domain stammt.
DKIM-Kanonisierung: Die zwei Algorithmen simple und relaxed (RFC 6376 §3.4), die Header und Body einer Nachricht vor dem DKIM-Hashing normalisieren; für Header und Body werden sie unabhängig voneinander mit dem Tag c= gewählt.
DKIM-Replay: Das erneute, unveränderte Versenden einer legitim DKIM-signierten Nachricht an viele neue Empfänger, damit sie die Reputation der signierenden Domain mitnimmt – DKIM kann das nicht verhindern, weil die Signatur den SMTP-Envelope nicht abdeckt.
DKIM-Signature-Header: Das Header-Feld (RFC 6376 §3.5), das eine DKIM-Signatur als tag=value-Paare trägt, darunter v, a, c, d, s, h, bh, b und die optionalen Tags i, l, t und x.
DMARC: Domain-based Message Authentication, Reporting and Conformance (RFC 9989, Mai 2026): eine DNS-Richtlinie, die verlangt, dass SPF oder DKIM mit Alignment zur sichtbaren From-Domain besteht, und Empfängern sagt, wie sie mit Mails umgehen sollen, die durchfallen.
DMARC-Alignment (Identifier Alignment): Die DMARC-Anforderung, dass die von SPF (Envelope-Absender) oder von DKIM (Domain in d=) authentifizierte Domain mit der Domain im From-Header übereinstimmt, entweder exakt (strict) oder innerhalb derselben Organisationsdomain (relaxed).
DNSSEC: Die DNS Security Extensions (RFC 4033–4035), die DNS-Record-Sets signieren, damit validierende Resolver prüfen können, dass Antworten unverändert vom Inhaber der Zone stammen – über eine Kette, die beim Schlüssel der Root-Zone beginnt.
DoH (DNS over HTTPS): Das Protokoll aus RFC 8484, das DNS-Abfragen und -Antworten in HTTPS-Anfragen transportiert (Medientyp application/dns-message), sie so vor Beobachtern auf dem Übertragungsweg verbirgt und Webanwendungen Namen direkt auflösen lässt.
Domain-Validierung (DV): Die Validierungsstufe für Zertifikate, bei der eine CA nur prüft, ob der Antragsteller über die Domainnamen im Zertifikat verfügt – per DNS-, HTTP- oder TLS-ALPN-Challenge –, und nichts über die Organisation.
Downgrade-Schutz: Mechanismen, die verhindern, dass ein Angreifer zwei Parteien, die eine starke Protokollversion oder einen starken Algorithmus unterstützen, auf eine schwächere Variante zwingt, etwa der Sentinel-Wert von TLS 1.3 in ServerHello.random.
DPoP (Demonstrating Proof of Possession): Der OAuth-Mechanismus aus RFC 9449, der Access Tokens und Refresh Tokens an einen Schlüssel des Clients bindet: Jede Anfrage trägt ein frisch signiertes DPoP-Proof-JWT, sodass ein gestohlenes Token allein nutzlos ist.
DSA (Digitaler Signaturalgorithmus): Der Signaturalgorithmus aus FIPS 186 (1994), der auf dem diskreten Logarithmus in endlichen Körpern beruht; FIPS 186-5 hat ihn 2023 für neue Signaturen zurückgezogen und nur noch zum Prüfen bestehender Signaturen beibehalten.

E

ECDH (Diffie-Hellman auf elliptischen Kurven): Schlüsseleinigung, bei der jede Partei ihren eigenen privaten Schlüssel auf einer elliptischen Kurve mit dem öffentlichen Schlüssel der anderen kombiniert und so dasselbe gemeinsame Geheimnis berechnet: die x-Koordinate von d_A·d_B·G.
ECDH-ES (Schlüsseleinigung in JWE): Die Familie von JWE-Verfahren zur Schlüsselverwaltung aus RFC 7518 §4.6, bei der der Absender einen ephemeren EC-Schlüssel erzeugt, mit dem statischen Schlüssel des Empfängers ein Geheimnis vereinbart und daraus mit der Concat-KDF den Inhaltsschlüssel ableitet.
ECDHE (ephemeres Diffie-Hellman auf elliptischen Kurven): Diffie-Hellman auf elliptischen Kurven mit neuen Schlüsselpaaren für jeden Handshake – der Schlüsselaustausch, der TLS Forward Secrecy verleiht; in TLS 1.3 läuft er über x25519, secp256r1 und ähnliche Gruppen.
ECDLP (diskreter Logarithmus auf elliptischen Kurven): Das Problem, aus den Punkten G und Q = d·G auf einer elliptischen Kurve den Skalar d zu bestimmen; seine Schwierigkeit ist die Sicherheitsannahme hinter ECDSA, EdDSA, ECDH und Schnorr-Signaturen.
ECDSA (Signaturalgorithmus mit elliptischen Kurven): Die Variante von DSA auf elliptischen Kurven, spezifiziert in FIPS 186-5 und SEC 1; die Signatur ist ein Paar ganzer Zahlen (r, s), berechnet mit einem privaten Skalar und einer frischen, geheimen Nonce.
ECDSA-Public-Key-Recovery: Das Berechnen des öffentlichen Schlüssels des Signierers aus einer ECDSA-Signatur und dem Hash der Nachricht (SEC 1 §4.1.6); Ethereum und Bitcoin nutzen es beim Signieren von Nachrichten, statt den Schlüssel zu übertragen.
ECH (Encrypted Client Hello): Die Erweiterung von TLS 1.3 aus RFC 9849, die das echte ClientHello samt Servernamen mit einem im DNS veröffentlichten Schlüssel verschlüsselt; für das Netz sichtbar bleibt nur ein gemeinsamer öffentlicher Name.
ecrecover: Der vorkompilierte Ethereum-Contract an der Adresse 0x01 (dazu die Solidity-Funktion ecrecover), der aus einem 32-Byte-Hash und einer ECDSA-Signatur (v, r, s) auf secp256k1 die Adresse des Signierers wiederherstellt.
Ed448: EdDSA auf der Kurve Edwards448 („Goldilocks“) mit SHAKE256 (RFC 8032 §5.2): etwa 224 Bit Sicherheit, öffentliche Schlüssel mit 57 Byte und 114-Byte-Signaturen.
Ed25519: EdDSA auf Curve25519 in Edwards-Form mit SHA-512 (RFC 8032 §5.1): öffentliche Schlüssel (32 Byte), deterministische 64-Byte-Signaturen, etwa 128 Bit Sicherheit.
EdDSA (Signaturalgorithmus mit Edwards-Kurven): Ein Schnorr-artiges Signaturverfahren auf Twisted-Edwards-Kurven, definiert in RFC 8032 und zugelassen in FIPS 186-5; seine beiden Standardinstanzen sind Ed25519 und Ed448.
eIDAS: Die EU-Verordnung über elektronische Identifizierung und Vertrauensdienste (Nr. 910/2014, geändert durch 2024/1183), nach der qualifizierte elektronische Signaturen die gleiche Rechtswirkung haben wie handschriftliche Unterschriften.
EIP-155 (Replay-Schutz): Die Ethereum-Änderung von 2016 (Spurious Dragon, Block 2.675.000), die die Chain-ID in den signierten Hash der Transaktion und in den Wert v aufnimmt (v = chainId × 2 + 35 oder 36), sodass eine Transaktion für eine Chain auf anderen ungültig ist.
EIP-191 (Standard für signierte Daten): Die Ethereum-Konvention, nach der signierte Nachrichten mit dem Byte 0x19 und einem Versionsbyte beginnen, sodass sie nie gültige Transaktionen sein können; Version 0x45 ist das Format von personal_sign, das die meisten Wallets nutzen.
EIP-712 (Signieren typisierter Daten): Der Ethereum-Standard zum Hashen und Signieren typisierter, strukturierter Daten mit einem Domain Separator, damit Wallets Nutzern die Felder anzeigen können und sich Signaturen nicht in anderen Contracts oder auf anderen Chains erneut verwenden lassen.
EIP-7702 (Code für EOAs setzen): Das Ethereum-Upgrade, aktiv seit dem Pectra-Hard-Fork am 7. Mai 2025, mit dem ein Konto mit eigenem Schlüssel (Externally Owned Account) seinen Code über eine signierte Autorisierung in einer Transaktion vom Typ 0x04 an einen Contract delegieren kann.
Elliptische Kurve: Die Menge der Punkte, die eine kubische Gleichung wie y² = x³ + ax + b über einem endlichen Körper erfüllen, mit einem Additionsgesetz für Punkte, das die von ECDSA, EdDSA und ECDH genutzte Gruppe bildet.
ERC-1271 (Signaturprüfung durch Contracts): Der Ethereum-Standard, mit dem Smart-Contract-Konten Signaturen validieren: Ein Verifizierer ruft isValidSignature(bytes32 hash, bytes signature) auf und wertet den Rückgabewert 0x1626ba7e als gültig.
ES256: Der JWS-Algorithmus für ECDSA auf der Kurve P-256 mit SHA-256 (RFC 7518 §3.4), dessen Signatur genau 64 Byte rohes r‖s statt DER ist; auch COSE-Algorithmus −7.
Ethereum-Adresse: Eine 20 Byte lange Kontokennung: bei Konten mit eigenem Schlüssel (EOAs) die letzten 20 Byte des Keccak-256-Hashes des unkomprimierten öffentlichen Schlüssels auf secp256k1 (64 Byte, ohne das Präfix 0x04), geschrieben als 0x plus 40 Hexziffern.
EUDI-Wallet (Wallet für digitale Identität): Die Identitäts-Wallet, die jeder EU-Mitgliedstaat seinen Bürgern nach der Verordnung (EU) 2024/1183 (eIDAS 2) anbieten muss; sie enthält Personenidentifizierungsdaten und Attributsbescheinigungen in den Formaten SD-JWT VC und mdoc.
exp (Ablaufzeitpunkt-Claim): Der registrierte JWT-Claim (RFC 7519 §4.1.4) mit dem Zeitpunkt in Sekunden seit der Unix-Epoche, ab dem das Token nicht mehr akzeptiert werden darf.
Extended Key Usage (EKU): Die X.509-Erweiterung (OID 2.5.29.37), die die Anwendungszwecke aufführt, für die der Schlüssel eines Zertifikats verwendet werden darf, etwa id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning oder id-kp-emailProtection.
Extended Validation (EV): Die strengste Validierungsstufe für TLS-Zertifikate, festgelegt in den EV Guidelines des CA/Browser Forum, bei der die CA die rechtliche, physische und operative Existenz der Organisation prüft und Details der Registrierung ins Zertifikat schreibt.

F

Falcon (FN-DSA): Ein kompaktes gitterbasiertes Signaturverfahren auf NTRU-Gittern, 2022 von NIST ausgewählt; es wird als FN-DSA in FIPS 206 standardisiert, der im Oktober 2026 noch ein Entwurf war.
FIDO Metadata Service (MDS): Der signierte Feed der FIDO Alliance mit Metadata Statements zertifizierter Authenticators – AAGUIDs, Root-Zertifikate für die Attestierung, Fähigkeiten und Zertifizierungsstatus –, mit dem Attestierungen geprüft werden.
FIDO2: Der Oberbegriff der FIDO Alliance für passwortlose Public-Key-Authentifizierung, bestehend aus der WebAuthn-API des W3C und dem FIDO Client to Authenticator Protocol (CTAP 2.x).
Fingerabdruck eines Schlüssels oder Zertifikats: Ein kurzer Hash eines öffentlichen Schlüssels oder Zertifikats, mit dem sich der Schlüssel oder das Zertifikat mit bloßem Auge oder in Konfigurationen identifizieren und vergleichen lässt, etwa SHA256:… bei SSH-Schlüsseln oder der SHA-256-Hash der DER-Bytes eines Zertifikats.
FIPS 140-3: Der US-amerikanische und kanadische Standard für kryptografische Module (2019, abgestimmt auf ISO/IEC 19790), nach dem das CMVP Hardware- und Softwaremodule auf den Sicherheitsniveaus 1 bis 4 validiert.
Forward Secrecy: Die Eigenschaft, dass die Kompromittierung langlebiger Schlüssel, etwa des Zertifikatsschlüssels eines Servers, vergangene Sitzungen nicht offenlegt; erreicht wird sie, indem die Schlüssel jeder Sitzung aus einem Schlüsselaustausch mit ephemeren Schlüsseln abgeleitet werden, die danach verworfen werden.

G

Gitterbasierte Kryptografie: Kryptografie, die auf schwierigen Gitterproblemen in hohen Dimensionen beruht, etwa Learning With Errors und dem Short-Integer-Solution-Problem; sie ist die Basis von ML-KEM, ML-DSA und FN-DSA.
Grover-Algorithmus: Der Quanten-Suchalgorithmus von Lov Grover aus dem Jahr 1996, der ein markiertes Element unter N in etwa √N Schritten findet und daher die effektive Bitsicherheit symmetrischer Schlüssel und von Hash-Urbildern höchstens halbiert.

H

Hardware-Wallet: Ein dediziertes Gerät, das die Schlüssel einer Wallet in einem Secure Element oder einem isolierten Mikrocontroller speichert, Transaktionsdetails auf seinem eigenen Display anzeigt und erst nach physischer Bestätigung signiert.
Harvest now, decrypt later: Die Strategie „jetzt speichern, später entschlüsseln“: verschlüsselten Datenverkehr heute aufzeichnen, um ihn zu entschlüsseln, sobald ein Quantencomputer seinen Schlüsselaustausch brechen kann – der Grund, warum Post-Quanten-Schlüsselaustausch schon eingeführt wird, bevor es Quantencomputer gibt.
Hashbasierte Signaturen: Signaturverfahren, deren Sicherheit nur von Eigenschaften einer Hashfunktion abhängt, aufgebaut aus Einmalsignaturen und Merkle-Bäumen: die zustandsbehafteten Verfahren LMS und XMSS (SP 800-208) und das zustandslose SLH-DSA (FIPS 205).
Hedged-Signaturen: Signieren, bei dem die Nonce jeder Signatur aus dem privaten Schlüssel und der Nachricht zusammen mit frischem Zufall abgeleitet wird, sodass das Verfahren sicher bleibt, wenn entweder der Zufallszahlengenerator oder die deterministische Ableitung angegriffen wird.
Hidden Number Problem: Das Gitterproblem, ein Geheimnis aus vielen verrauschten linearen Relationen zu rekonstruieren, die einige seiner Bits verraten; es macht aus kleinen Verzerrungen oder Lecks in ECDSA- und DSA-Nonces die vollständige Rekonstruktion des privaten Schlüssels.
HKDF: Die HMAC-basierte Schlüsselableitungsfunktion nach dem Extract-and-Expand-Prinzip aus RFC 5869, die ein gemeinsames Geheimnis wie die Ausgabe von ECDH in einen oder mehrere gleichverteilt zufällige Schlüssel umwandelt, die an einen Kontext-String gebunden sind.
HMAC: Der schlüsselabhängige, hashbasierte Message Authentication Code aus RFC 2104 und FIPS 198-1, berechnet als H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)), der jedem, der den geheimen Schlüssel kennt, Integrität und Herkunft beweist.
HQC (Hamming Quasi-Cyclic): Ein codebasiertes Schlüsselkapselungsverfahren, das NIST am 11. März 2025 als Reserveverfahren neben ML-KEM ausgewählt hat und das als FIPS 207 geplant ist; der Entwurf des Standards war bis Oktober 2026 nicht veröffentlicht.
HS256: Der JWS-Algorithmus HMAC mit SHA-256 (RFC 7518 §3.2), bei dem sich Aussteller und Verifizierer einen geheimen Schlüssel von mindestens 256 Bit teilen, sodass jeder, der ein Token prüfen kann, auch selbst eines ausstellen kann.
HSM (Hardware-Sicherheitsmodul): Ein manipulationsresistentes Gerät oder ein Cloud-Dienst, in dessen Grenzen Schlüssel erzeugt und gespeichert und kryptografische Operationen ausgeführt werden, sodass private Schlüssel nicht im Klartext exportiert werden können.
HSTS (HTTP Strict Transport Security): Der HTTP-Antwort-Header aus RFC 6797, der Browsern vorschreibt, einen Host für eine festgelegte Zeit nur über HTTPS aufzurufen, bei Zertifikatsfehlern kein Weiterklicken zuzulassen und jeden http://-Link automatisch auf HTTPS umzustellen.
HTTP Message Signatures: Der IETF-Standard (RFC 9421, Februar 2024) zum Signieren ausgewählter Komponenten einer HTTP-Anfrage oder -Antwort; die Signaturen stehen in den Header-Feldern Signature-Input und Signature.
Hybrider Schlüsselaustausch: Ein Schlüsselaustausch, der einen klassischen Algorithmus wie X25519 mit einem Post-Quanten-KEM wie ML-KEM kombiniert, sodass die Sitzung geheim bleibt, solange mindestens eine der beiden Komponenten ungebrochen ist.

I

ID-Token: Das JWT, das ein Anbieter von OpenID Connect einem Client ausstellt, um zu bestätigen, dass sich ein Benutzer authentifiziert hat; es enthält mindestens die Claims iss, sub, aud, exp und iat und ist vom Anbieter signiert.
in-toto: Ein Framework der CNCF (Status Graduated) für signierte Aussagen über die Software-Lieferkette, dessen Attestierungsformat – ein Statement, das Digests von Artefakten an ein typisiertes Predicate bindet – SLSA-Provenance und SBOM-Attestierungen transportiert.
Invalid-Curve-Angriff (ungültige Kurve): Ein Angriff, bei dem eine Gegenstelle einen Punkt sendet, der nicht auf der vereinbarten Kurve liegt, sodass eine Implementierung ohne Punktvalidierung auf einer schwächeren Kurve rechnet und ihren privaten Schlüssel Stück für Stück preisgibt.
iss (Aussteller-Claim): Der registrierte JWT-Claim (RFC 7519 §4.1.1), der angibt, wer ein Token ausgestellt hat; ein Verifizierer muss ihn exakt mit dem Aussteller vergleichen, mit dessen Schlüsseln er die Signatur geprüft hat.

J

JA4 (Fingerabdruck von TLS-Clients): Die Methode von FoxIO aus dem Jahr 2023, die aus dem ClientHello eines TLS-Clients einen Fingerabdruck bildet (Protokoll, Version, SNI, Anzahl und sortierte Hashes der Cipher Suites und Erweiterungen) und so ausgelegt ist, dass er stabil bleibt, wenn Browser die Reihenfolge der Erweiterungen zufällig mischen.
JOSE (JSON Object Signing and Encryption): Die IETF-Familie JSON-basierter Formate zum Signieren, Verschlüsseln und Darstellen von Schlüsseln – JWS, JWE, JWK, JWA und JWT (RFC 7515–7519) – sowie die Arbeitsgruppe, die sie pflegt.
JWA (JSON Web Algorithms): RFC 7518, der die Algorithmusbezeichner und Parameter für JWS, JWE und JWK festlegt, etwa HS256, RS256, ES256, PS256, RSA-OAEP, ECDH-ES und A256GCM.
JWE (JSON Web Encryption): Das JOSE-Format aus RFC 7516 für verschlüsselte Inhalte; seine kompakte Form hat fünf Teile – Header, verschlüsselter Schlüssel, IV, Chiffrat und Tag –, und es trennt das Schlüsselmanagement (alg) von der Inhaltsverschlüsselung (enc).
JWK (JSON Web Key): Die JSON-Darstellung eines kryptografischen Schlüssels (RFC 7517) mit Feldern wie kty, crv, x, y, n und e für öffentliche Schlüssel und d für den privaten Teil.
JWK-Thumbprint: Ein Hash über die Pflichtfelder eines JWK in kanonischer Form als JSON (RFC 7638), meist SHA-256, base64url-kodiert, der als stabile Schlüsselkennung für kid-Werte, DPoP-Bindungen und ACME dient.
JWKS (JSON Web Key Set): Ein JSON-Objekt mit öffentlichen JWKs im Array keys, meist unter der jwks_uri des Ausstellers, damit die Relying Party Tokens prüft und der Rotation folgt.
JWS (JSON Web Signature): Das JOSE-Format aus RFC 7515 für Inhalte, die mit in JSON beschriebenen Parametern signiert oder per MAC geschützt sind, kompakt serialisiert als header.payload.signature oder als JSON mit mehreren Signaturen.
JWT (JSON Web Token): Ein kompaktes, URL-sicheres Token (RFC 7519) mit einem JSON-Objekt aus Claims, signiert als JWS oder verschlüsselt als JWE, verwendet für ID-Tokens, Access Tokens und viele API-Sitzungen.

K

Kanonisierung: Die Umwandlung von Daten in eine einzige vereinbarte Bytedarstellung vor dem Hashen oder Signieren, damit semantisch gleiche Eingaben (abweichender Whitespace, andere Reihenfolge der Schlüssel, andere Namespace-Präfixe oder gefaltete Header) dieselbe Eingabe für die Signatur ergeben.
Keccak-256: Der ursprüngliche Keccak-Hash mit 256-Bit-Ausgabe und dem Padding aus der Zeit vor dem Standard, den Ethereum für Adressen, Funktionsselektoren und zu signierende Hashes nutzt; er ist nicht dieselbe Funktion wie SHA3-256 aus FIPS 202.
KEM (Schlüsselkapselungsverfahren): Ein Public-Key-Primitiv, bei dem Encaps aus einem öffentlichen Schlüssel ein zufälliges gemeinsames Geheimnis und ein Chiffrat erzeugt und Decaps das Geheimnis mit dem privaten Schlüssel zurückgewinnt; im Post-Quanten-Schlüsselaustausch ersetzt es Diffie-Hellman.
Key Binding (Bindung an den Inhaber): Der Nachweis, dass die Partei, die ein Credential vorlegt, über einen darin genannten privaten Schlüssel verfügt, sodass niemand sonst ein kopiertes Credential erneut vorlegen kann; umgesetzt durch das Key-Binding-JWT von SD-JWT und die Geräteauthentifizierung von mdoc.
key_share (TLS-Erweiterung): Die Erweiterung (51) von TLS 1.3, die die ephemeren öffentlichen Werte des Clients für eine oder mehrere Gruppen und die einzelne Antwort des Servers überträgt, sodass der Schlüsselaustausch im ersten Roundtrip abgeschlossen ist.
Key-Usage-Erweiterung: Die X.509-Erweiterung (OID 2.5.29.15), deren Bits einschränken, wofür ein zertifizierter Schlüssel verwendet werden darf: digitalSignature, contentCommitment, keyEncipherment, keyAgreement, keyCertSign, cRLSign und weitere.
Keyless Signing (schlüsselloses Signieren): Das Signiermodell von Sigstore, bei dem sich der Signierer mit einer OIDC-Identität authentifiziert, für einen ephemeren Schlüssel ein nur minutenlang gültiges Zertifikat erhält und sich auf ein Transparenzlog stützt, statt einen langlebigen privaten Schlüssel zu schützen.
kid (Schlüssel-ID): Der Parameter in JOSE-Header und JWK, der den Schlüssel nennt, der ein Token signiert oder verschlüsselt, damit Verifizierer ihn bei Rotation im JWKS finden.
Kofaktor: Das Verhältnis h = #E / n zwischen der Anzahl der Punkte auf einer elliptischen Kurve und der Primordnung n der für die Kryptografie genutzten Untergruppe: 1 für die NIST-P-Kurven und secp256k1, 8 für Curve25519, 4 für Curve448.
Kryptoagilität: Die Fähigkeit eines Systems, kryptografische Algorithmen, Schlüssellängen und Parameter ohne grundlegenden Umbau zu wechseln (über Aushandlung, Konfiguration und ein Inventar); der Übergang zur Post-Quanten-Kryptografie macht sie von einer Best Practice zur Notwendigkeit.
Kryptografische Hashfunktion: Eine Funktion, die eine Eingabe beliebiger Länge auf einen Digest fester Länge abbildet, sodass es mit realistischem Rechenaufwand unmöglich ist, ein Urbild, ein zweites Urbild oder überhaupt eine Kollision zu finden.
Kurzlebiges Zertifikat: Ein Zertifikat mit so kurzer Gültigkeit – höchstens 7 Tage bei öffentlichen TLS-Zertifikaten, die seit dem 15. März 2026 ausgestellt wurden –, dass es einfach abläuft, statt sich auf Widerrufsprüfungen zu verlassen.
Kyber (CRYSTALS-Kyber): Die NIST-Einreichung (Runde 3), aus der ML-KEM entstand; früh in hybridem TLS genutzt (X25519Kyber768Draft00), nicht interoperabel mit standardisiertem ML-KEM.

L

Length-Extension-Angriff: Ein Angriff auf Hashes nach Merkle–Damgård wie MD5, SHA-1, SHA-256 und SHA-512, der aus H(secret ‖ m) und der Länge von secret ‖ m den Wert H(secret ‖ m ‖ padding ‖ m′) berechnet, ohne das Secret zu kennen.
LibrePGP: Eine OpenPGP-Spezifikation, die der Autor von GnuPG pflegt (draft-koch-librepgp); sie führt die Linie von RFC 4880bis mit v5-Schlüsseln und einer eigenen Composite-Verschlüsselung mit Kyber fort und ist mit den v6-Schlüsseln aus RFC 9580 inkompatibel.
LMS und HSS (Leighton-Micali-Signaturen): Das zustandsbehaftete hashbasierte Signaturverfahren aus RFC 8554 und NIST SP 800-208, bei dem ein Merkle-Baum aus Winternitz-Einmalschlüsseln eine feste Anzahl von Nachrichten signiert und HSS für mehr Signaturen Bäume übereinander stapelt.
Low-S-Normalisierung: Die Regel, nach der der Wert s einer ECDSA-Signatur in der unteren Hälfte des Wertebereichs liegen muss (s ≤ n/2); Bitcoin und Ethereum haben sie eingeführt, um die in ECDSA eingebaute Malleability von Signaturen zu beseitigen.

M

MD5: Die 128-Bit-Hashfunktion von Ron Rivest aus dem Jahr 1991 (RFC 1321), deren Kollisionsresistenz seit 2004 und deren Resistenz gegen Chosen-Prefix-Kollisionen seit 2007 gebrochen ist; unsicher für jeden Sicherheitszweck, bei dem ein Angreifer die Eingabe beeinflussen kann.
mDL (mobiler Führerschein): Ein Führerschein oder amtlicher Ausweis, der als mdoc nach ISO/IEC 18013-5 auf dem Smartphone liegt und vor Ort per NFC oder Bluetooth oder online vorgelegt wird, wobei jedes Datenelement einzeln offengelegt wird und von der ausstellenden Behörde signiert ist.
mdoc (mobiles Dokument nach ISO/IEC 18013-5): Das CBOR-basierte Credential-Format aus ISO/IEC 18013-5, entwickelt für mobile Führerscheine: Ein Aussteller signiert Digests der einzelnen Datenelemente in einem Mobile Security Object, und das Gerät weist den Besitz mit seinem eigenen Schlüssel nach.
Merkle Tree Certificates (MTC): Ein Zertifikatsverfahren, das die IETF gerade standardisiert: Eine CA protokolliert jede Ausstellung in einem Merkle-Baum, und Clients prüfen statt großer Post-Quanten-Signaturen einen kurzen Inclusion-Proof.
Merkle-Baum: Ein binärer Hash-Baum, in dem jeder innere Knoten den Hash seiner beiden Kindknoten bildet, sodass ein einziger Root-Hash alle Blätter festschreibt und sich die Zugehörigkeit eines Eintrags oder ein Wachstum nur durch Anhängen mit Beweisen logarithmischer Größe nachweisen lässt.
ML-DSA (FIPS 204): Der modulgitterbasierte Signaturalgorithmus (Module-Lattice-Based Digital Signature Algorithm) aus FIPS 204 (August 2024), hervorgegangen aus CRYSTALS-Dilithium: das primäre Post-Quanten-Signaturverfahren des NIST mit den Parametersätzen ML-DSA-44, ML-DSA-65 und ML-DSA-87.
ML-KEM (FIPS 203): Das modulgitterbasierte Schlüsselkapselungsverfahren (Module-Lattice-Based Key-Encapsulation Mechanism) aus FIPS 203 (August 2024), hervorgegangen aus CRYSTALS-Kyber: der Standard für den Post-Quanten-Schlüsselaustausch mit den Parametersätzen ML-KEM-512, ML-KEM-768 und ML-KEM-1024.
mlkem768x25519-sha256: Der hybride Schlüsselaustausch für SSH aus ML-KEM-768 mit X25519 und SHA-256, standardisiert in RFC 10042 und seit OpenSSH 10.0 (April 2025) die Voreinstellung.
MTA-STS (SMTP MTA Strict Transport Security): Der Mechanismus aus RFC 8461, mit dem eine Maildomain über HTTPS eine Richtlinie veröffentlicht, nach der Absender nur per TLS mit gültigem Zertifikat an die aufgeführten MX-Hosts zustellen dürfen.
mTLS (Mutual TLS): TLS, bei dem sich auch der Client mit einem Zertifikat und einer CertificateVerify-Signatur authentifiziert, sodass beide Seiten den Besitz privater Schlüssel nachweisen; üblich für Verkehr zwischen Diensten, für Geräte und für sendergebundene Tokens in OAuth.
MuSig2: Das Zwei-Runden-Multisignaturverfahren aus BIP-327, bei dem n Signierer gemeinsam eine einzige Schnorr-Signatur nach BIP-340 erzeugen, die unter einem aggregierten öffentlichen Schlüssel gültig ist und sich on-chain nicht von einer Ausgabe mit nur einem Signierer unterscheiden lässt.

N

Name Constraints: Die X.509-Erweiterung (OID 2.5.29.30), die nur in CA-Zertifikaten zulässig ist und über erlaubte und ausgeschlossene Teilbäume aus DNS-Namen, IP-Bereichen, E-Mail-Domains und Verzeichnisnamen begrenzt, welche Namen untergeordnete Zertifikate enthalten dürfen.
NIST IR 8547: Das Dokument „Transition to Post-Quantum Cryptography Standards“ des NIST, ein erster öffentlicher Entwurf vom November 2024, der vorschlägt, quantenanfällige Algorithmen mit 112-Bit-Sicherheit nach 2030 als veraltet einzustufen und nach 2035 überhaupt keine quantenanfälligen Algorithmen mehr zuzulassen.
Nonce (k bei ECDSA): Eine nur einmal verwendete Zahl; bei ECDSA-, DSA- und Schnorr-Signaturen das geheime k jeder Signatur, das außerdem unvorhersagbar und gleichverteilt sein muss.
Nostr: Ein dezentrales Protokoll für soziale Netzwerke und Nachrichten, in dem Nutzer secp256k1-Schlüsselpaare sind und jedes Event ein JSON-Objekt ist, das über seinen SHA-256-Hash identifiziert und mit einer Schnorr-Signatur nach BIP-340 signiert wird.
npm-Provenance: Signierte SLSA-Provenance, die an npm-Pakete angehängt wird, wenn sie aus einer unterstützten CI veröffentlicht werden (allgemein verfügbar seit dem 26. September 2023), und die jede Paketversion mit ihrem Quell-Repository, Commit und Build-Workflow verknüpft.

O

OAuth 2.0: Das Autorisierungs-Framework aus RFC 6749 (2012), in dem ein Autorisierungsserver Clients Access Tokens ausstellt, damit sie APIs mit delegierten, auf Scopes begrenzten Berechtigungen statt mit Benutzerpasswörtern aufrufen können.
OCSP (Online Certificate Status Protocol): Das Protokoll aus RFC 6960, bei dem ein Client den Responder einer CA fragt, ob ein bestimmtes Zertifikat widerrufen ist, und eine signierte Antwort mit dem Status good, revoked oder unknown und einem Gültigkeitszeitraum erhält.
OCSP-Stapling: Eine TLS-Funktion, bei der der Server eine frische OCSP-Antwort für sein eigenes Zertifikat abruft und im Handshake mitsendet, sodass Clients sich eine Abfrage bei der CA sparen, die ihre Privatsphäre gefährdet.
OID (Object Identifier): Eine global eindeutige, durch Punkte gegliederte Folge von Ganzzahlen wie 1.2.840.10045.2.1, die über einen delegierten Registrierungsbaum vergeben und in ASN.1 verwendet wird, um Algorithmen, Kurven, Erweiterungen und Richtlinien zu benennen.
OIDC (OpenID Connect): Die Identitätsschicht auf OAuth 2.0 (OpenID Connect Core 1.0, 2014), mit der ein Client über ein signiertes ID-Token prüft, wer ein Benutzer ist, und Profil-Claims von einem UserInfo-Endpunkt abruft.
OpenID4VP (OpenID for Verifiable Presentations): Das Protokoll der OpenID Foundation (Final 1.0, Juli 2025), mit dem ein Verifizierer Credentials von einer Wallet anfordert und eine Präsentation erhält; es baut auf OAuth 2.0 auf und wird von der EU-Wallet für die digitale Identität (EUDI-Wallet) genutzt.
OpenPGP: Der IETF-Standard für Public-Key-Verschlüsselung und Signaturen von Nachrichten und Dateien mit selbst verwalteten Schlüsseln (RFC 9580, Juli 2024), implementiert von GnuPG, Sequoia, OpenPGP.js und anderen.
OpenPGP-v6-Schlüssel: Das mit RFC 9580 eingeführte Schlüsselformat mit 32-Byte-Fingerabdrücken aus SHA-256, nativen Algorithmen Ed25519/X25519/Ed448/X448 und v6-Signaturen mit Salt; es ersetzt die SHA-1-basierten v4-Schlüssel aus RFC 4880.
OpenSSH-Format für private Schlüssel: Der Container openssh-key-v1, den ssh-keygen seit OpenSSH 7.8 (2018) standardmäßig schreibt, gespeichert als -----BEGIN OPENSSH PRIVATE KEY----- und bei gesetzter Passphrase mit einer bcrypt-basierten KDF verschlüsselt.
Organisationsvalidierung (OV): Die Validierungsstufe für Zertifikate, bei der die CA zusätzlich zur Kontrolle über die Domain die rechtliche Existenz, den Namen und die Anschrift der antragstellenden Organisation prüft und diese Angaben in das Subject des Zertifikats schreibt.

Ö

Öffentlicher Schlüssel: Die Hälfte eines asymmetrischen Schlüsselpaars, die frei weitergegeben werden kann und dazu dient, Signaturen zu prüfen, für den Inhaber des passenden privaten Schlüssels zu verschlüsseln oder mit ihm Schlüssel zu vereinbaren.

P

P-256 (secp256r1): Die elliptische Kurve des NIST über einem 256-Bit-Primkörper, auch secp256r1 und prime256v1 genannt, mit etwa 128 Bit Sicherheit; die am weitesten verbreitete Kurve für ECDSA und ECDH.
P-384 (secp384r1): Die elliptische Kurve des NIST über einem Primkörper, mit einer Ordnung von 384 Bit und etwa 192 Bit Sicherheit; vorgeschrieben in der Suite CNSA 1.0 der NSA und verbreitet in Hierarchien von Behörden und CAs.
P-521 (secp521r1): Die größte Primkörper-Kurve des NIST, definiert über der Mersenne-Primzahl 2⁵²¹ − 1, mit etwa 256 Bit Sicherheit; ES512 in JOSE bedeutet ECDSA auf P-521 mit SHA-512, keine 512-Bit-Kurve.
PAdES: Das ETSI-Profil der PDF-Signatur (EN 319 142) für fortgeschrittene elektronische Signaturen nach eIDAS, mit den Baseline-Stufen B-B, B-T (mit Zeitstempel), B-LT (mit eingebetteten Validierungsdaten) und B-LTA (mit Archivzeitstempeln).
PASETO (Platform-Agnostic Security Tokens): Ein als einfachere Alternative zu JOSE konzipiertes Token-Format mit versionierten Protokollen statt verhandelbarer Algorithmen: v4.public-Tokens sind mit Ed25519 signiert, v4.local-Tokens mit XChaCha20 verschlüsselt und mit BLAKE2b als MAC authentifiziert.
Passkey: Ein Discoverable Credential nach FIDO2/WebAuthn – ein Schlüsselpaar, das an eine Website oder App gebunden ist und per Biometrie, PIN oder Passwort des Geräts entsperrt wird –, das ein Passwort durch eine phishing-resistente Signatur ersetzt.
Passwort: Eine geheime Zeichenkette, die sich ein Benutzer merkt und ein Server prüft; der verbreitetste und am leichtesten per Phishing abgreifbare Authenticator, den NIST SP 800-63B-4 über Länge, Blocklisten und Speicherregeln statt über Komplexität regelt.
Passwort-Hashing: Das Speichern eines Passworts als Ausgabe einer absichtlich langsamen, vorzugsweise speicherharten Funktion mit Salt wie Argon2id, scrypt, bcrypt oder PBKDF2, damit eine gestohlene Datenbank Offline-Rateangriffen standhält.
PDF-Signatur: Eine in eine PDF-Datei eingebettete digitale Signatur (ISO 32000-2), deren /ByteRange alles außer dem Signaturwert abdeckt, meist eine abgetrennte CMS- oder CAdES-Signatur mit Zertifikatskette und Zeitstempel.
PEM: Das Textformat, das DER-Daten als base64 zwischen den Zeilen -----BEGIN label----- und -----END label----- einschließt; für PKIX-Objekte in RFC 7468 standardisiert und von den meisten Tools zum Speichern von Zertifikaten und Schlüsseln verwendet.
Permit (EIP-2612 und Permit2): Token-Genehmigungen per Signatur: Eine Off-Chain-Signatur nach EIP-712 erlaubt einer berechtigten Adresse (spender), Tokens zu übertragen, und ersetzt eine On-Chain-Transaktion mit approve – entweder pro Token (EIP-2612) oder über den gemeinsamen Permit2-Contract von Uniswap.
personal_sign: Die Wallet-Methode von Ethereum in JSON-RPC, die eine Nachricht mit dem Präfix nach EIP-191, Version 0x45, signiert und eine 65-Byte-Signatur r‖s‖v zurückgibt; der Standardweg für die Anmeldung und das einfache Signieren von Nachrichten.
Phishing-Resistenz: Die Eigenschaft eines Authentifizierungsverfahrens, dass eine täuschend ähnliche Website keine Anmeldedaten abgreifen und erneut verwenden kann; erreicht wird sie, wenn der Authenticator seine Antwort kryptografisch an den echten Origin bindet, wie bei WebAuthn und TLS mit Client-Zertifikaten.
PIV (Personal Identity Verification): Der Smartcard-Standard der US-Bundesbehörden (FIPS 201-3, 2022) mit seiner Kartenschnittstelle (SP 800-73): Die Schlüsselslots 9A, 9C, 9D und 9E enthalten Schlüssel für Authentifizierung, Signatur, Schlüsselmanagement und Kartenauthentifizierung; YubiKeys und andere Tokens implementieren den Standard.
PKCE (Proof Key for Code Exchange): Die OAuth-Erweiterung aus RFC 7636, bei der der Client mit der Autorisierungsanfrage einen Hash eines zufälligen code_verifier sendet und mit der Token-Anfrage den Verifier selbst, sodass ein abgefangener Autorisierungscode nutzlos ist.
PKCS #8: Der vom Algorithmus unabhängige Container für private Schlüssel (PrivateKeyInfo, RFC 5208; OneAsymmetricKey, RFC 5958), in PEM gespeichert als -----BEGIN PRIVATE KEY----- oder, passwortgeschützt, als -----BEGIN ENCRYPTED PRIVATE KEY-----.
PKCS #12 (PFX): Das passwortgeschützte Archivformat aus RFC 7292, meist als .p12 oder .pfx gespeichert, das einen privaten Schlüssel mit seiner Zertifikatskette bündelt, um beides in Browser, Windows, macOS, Java und Android zu importieren.
Post-Quanten-Kryptografie (PQC): Public-Key-Algorithmen, die so entwickelt sind, dass sie auch gegenüber großen Quantencomputern sicher bleiben, etwa ML-KEM, ML-DSA und SLH-DSA (FIPS 203–205, 2024); sie lösen RSA, Diffie-Hellman und Verfahren auf Basis elliptischer Kurven ab.
Post-Quanten-Sicherheitskategorie des NIST: Eine von fünf Stärkestufen, die das NIST für Post-Quanten-Parametersätze im Vergleich mit dem Brechen von AES oder SHA-2/SHA-3 definiert: Kategorie 1 ≈ Schlüsselsuche bei AES-128, 3 ≈ AES-192, 5 ≈ AES-256; 2 und 4 sind an Kollisionen von SHA-256 und SHA3-384 gekoppelt.
Pre-Hash-Signieren (HashEdDSA, HashML-DSA): Das Signieren eines Digests der Nachricht statt der Nachricht selbst, entweder implizit (ECDSA, RSA) oder über ausdrücklich getrennte Varianten mit Domain-Separation wie Ed25519ph und HashML-DSA.
Privater Schlüssel: Die geheime Hälfte eines asymmetrischen Schlüsselpaars, die zum Signieren, Entschlüsseln oder zur Schlüsseleinigung dient; wer sie besitzt, kann als Eigentümer des Schlüssels auftreten, deshalb darf sie ihre Vertrauensgrenze nie ungeschützt verlassen.
PS256: Der JWS-Algorithmus RSASSA-PSS mit SHA-256 und MGF1-SHA-256 (RFC 7518 §3.5), der dieselben RSA-Schlüssel wie RS256 nutzt, jedoch mit dem randomisierten, beweisbar sicheren PSS-Padding.
PSBT (teilweise signierte Bitcoin-Transaktion): Das Austauschformat aus BIP-174 (Version 0) und BIP-370 (Version 2), das eine unsignierte Transaktion samt allen Daten transportiert, die Signierer brauchen, sodass Wallets, Hardwaregeräte und Koordinatoren in getrennten Schritten signieren können.
Punktkompression: Die Kodierung eines Punkts auf einer elliptischen Kurve durch seine x-Koordinate plus ein Bit von y statt durch beide Koordinaten, was die Größe öffentlicher Schlüssel ungefähr halbiert, dafür aber beim Dekodieren eine Quadratwurzel kostet.

Q

QUIC: Das UDP-basierte Transportprotokoll (RFC 9000), das den Handshake von TLS 1.3 einbettet (RFC 9001), fast alle Transportmetadaten verschlüsselt und HTTP/3 trägt.

R

RFC 6979 (deterministisches ECDSA): Die Spezifikation von Thomas Pornin aus dem Jahr 2013, die die Nonce k für DSA oder ECDSA mit HMAC-DRBG aus dem privaten Schlüssel und dem Hash der Nachricht ableitet, sodass das Signieren keinen Zufallszahlengenerator braucht.
Rohes Signaturformat r‖s (IEEE P1363): Die Kodierung einer ECDSA- oder DSA-Signatur mit fester Länge als Verkettung von r und s, jeweils links auf die Bytelänge der Gruppenordnung aufgefüllt; JOSE, COSE, WebCrypto und viele HSM-APIs verwenden sie.
Root Store (Trust Store): Die Menge der Root-CA-Zertifikate, denen ein Betriebssystem, ein Browser oder eine Laufzeitumgebung als Anker für die Pfadvalidierung von Zertifikaten vertraut, gepflegt von einem Root-Programm mit eigener Richtlinie.
Root-CA (Root-Zertifikat): Ein selbstsigniertes CA-Zertifikat, dem Verifizierer direkt vertrauen, weil es in ihrem Root Store liegt: der Anker, an dem jeder Zertifikatspfad enden muss.
RS256: Der JWS-Algorithmus RSASSA-PKCS1-v1_5 mit SHA-256 (RFC 7518 §3.3), historisch der Standard bei Anbietern für OpenID Connect, mit Signaturen so lang wie der RSA-Modul (256 Byte bei 2048-Bit-Schlüsseln).
RSA: Das Public-Key-Kryptosystem von Rivest, Shamir und Adleman (1977), dessen Sicherheit darauf beruht, dass sich ein großer Modul n = p·q nur schwer faktorisieren lässt, und das für Signaturen und historisch für den Schlüsseltransport genutzt wird.
RSA-OAEP: Die RSA-Verschlüsselung mit Optimal Asymmetric Encryption Padding (RFC 8017 §7.1), in JWE als RSA-OAEP (SHA-1) und RSA-OAEP-256 (SHA-256) zum Verpacken von Inhaltsschlüsseln genutzt; sie ersetzt die angreifbare Verschlüsselung nach PKCS #1 v1.5.
RSASSA-PKCS1-v1_5: Das deterministische RSA-Signaturpadding von PKCS #1 v1.5 (RFC 8017 §8.2), das den Hash in eine ASN.1-DigestInfo verpackt und diese mit 0xFF-Bytes auffüllt; es ist das RS256 von JWT und die häufigste RSA-Signatur in X.509.
RSASSA-PSS: Das randomisierte RSA-Signaturverfahren aus PKCS #1 ab v2.1 (RFC 8017 §8.1), das den Hash mit einem zufälligen Salt und der Maskenfunktion MGF1 kodiert und einen engen Sicherheitsbeweis hat, der PKCS #1 v1.5 fehlt.

S

S/MIME: Der Standard zum Signieren und Verschlüsseln von E-Mails mit X.509-Zertifikaten und CMS (RFC 8551, S/MIME 4.0), eingebaut in Outlook, Apple Mail und Thunderbird; für öffentlich vertrauenswürdige Zertifikate gelten die S/MIME Baseline Requirements des CA/Browser Forums.
Safe-Multisig (Safe Smart Account): Die meistgenutzte Smart-Contract-Wallet auf Ethereum, die eine Transaktion erst ausführt, wenn so viele Eigentümer, wie der Schwellenwert verlangt, den SafeTx-Hash (EIP-712) der Transaktion signiert haben; Signaturen können ECDSA-Signaturen, Contract-Signaturen (ERC-1271) oder On-Chain-Genehmigungen sein.
SAML 2.0: Der XML-Standard von OASIS (März 2005) für den Austausch signierter Authentifizierungs- und Attribut-Assertions zwischen einem Identity Provider und Service Providern, bis heute das Rückgrat von Single Sign-On in Unternehmen.
SBOM (Software-Stückliste): Ein maschinenlesbares Inventar der Komponenten, Versionen, Lizenzen und Abhängigkeitsbeziehungen einer Software, vor allem in SPDX oder CycloneDX ausgedrückt und für Schwachstellenmanagement und Compliance genutzt.
Schlüsselaustausch (Schlüsseletablierung): Ein Protokollschritt, mit dem zwei Parteien über einen unsicheren Kanal ein gemeinsames Geheimnis erhalten, per Schlüsseleinigung nach Diffie-Hellman oder per Schlüsselkapselung; aus dem Geheimnis werden die Sitzungsschlüssel abgeleitet.
Schlüsselformat PKCS #1: Die nur für RSA definierten ASN.1-Strukturen RSAPublicKey (öffentlicher Schlüssel) und RSAPrivateKey (privater Schlüssel) aus RFC 8017, Anhang A, die in PEM als -----BEGIN RSA PUBLIC KEY----- und -----BEGIN RSA PRIVATE KEY----- gespeichert werden.
Schlüsselpaar: Ein privater Schlüssel mit passendem öffentlichem Schlüssel eines asymmetrischen Algorithmus, möglichst nur für einen Zweck wie Signatur oder Schlüsseleinigung.
Schlüsselrotation: Das Ersetzen eines kryptografischen Schlüssels durch einen neuen, planmäßig oder nach einem Vorfall, wobei die Prüfung während des Wechsels weiter funktioniert – meist, indem alter und neuer Schlüssel nebeneinander veröffentlicht werden.
Schnorr-Signatur: Ein Signaturverfahren auf Basis des diskreten Logarithmus (Claus Schnorr, 1989), dessen Antwort s = r + e·x linear im Schlüssel ist; das ermöglicht einfache Sicherheitsbeweise, Batch-Prüfung und native Multisignaturen.
Schwacher Schlüssel: Ein Schlüssel, der leichter zu brechen ist, als seine Länge verspricht – durch Generatorfehler, wenig Entropie, Strukturfehler oder Kopien auf mehreren Geräten.
Schwellenwertsignaturen: Verfahren, bei denen ein privater Schlüssel so auf n Parteien aufgeteilt wird, dass beliebige t von ihnen gemeinsam eine einzige, gewöhnlich aussehende Signatur erzeugen können, während jede kleinere Gruppe nichts über den Schlüssel erfährt.
SCT (Signed Certificate Timestamp): Die signierte Zusage eines CT-Logs, ein Zertifikat oder Präzertifikat in sein öffentliches Log aufzunehmen; Clients erhalten sie eingebettet im Zertifikat, in einer TLS-Erweiterung oder in einer per Stapling mitgelieferten OCSP-Antwort.
SD-JWT (Selective Disclosure für JWTs): Das Format aus RFC 9901 (November 2025), bei dem ein Aussteller gesalzene Digests von Claims signiert und der Inhaber nur ausgewählte Claims offenlegt, indem er die passenden Disclosures mitsendet, optional mit einem Key-Binding-JWT.
SD-JWT VC: Der IETF-Internet-Draft, der SD-JWT für verifizierbare digitale Credentials profiliert: mit typ dc+sd-jwt, dem Claim vct für den Credential-Typ, Statusangaben und dem Auffinden der Ausstellerschlüssel; eines der beiden Credential-Formate der EUDI-Wallet.
SEC 1 ECPrivateKey: Die Struktur für private Schlüssel auf elliptischen Kurven aus SEC 1 und RFC 5915, die OpenSSL als -----BEGIN EC PRIVATE KEY----- schreibt; sie speichert den Skalar mit optionalen Kurvenparametern und dem öffentlichen Punkt.
secp256k1: Die 256-Bit-Koblitz-Kurve y² = x³ + 7 aus SEC 2, eine elliptische Kurve mit etwa 128 Bit Sicherheit; von Bitcoin gewählt, auch von Ethereum und Nostr genutzt.
Secure Enclave: Apples isolierter Sicherheits-Koprozessor in den Chips von iPhone, iPad, Mac und Apple Watch, der nicht exportierbare Schlüssel erzeugt und im Chip signiert oder entschlüsselt, optional abgesichert durch Face ID, Touch ID oder den Gerätecode.
security.txt: Eine Textdatei unter /.well-known/security.txt (RFC 9116), die Sicherheitsforschenden mitteilt, wie sie Schwachstellen an den Betreiber einer Website melden.
Seitenkanalangriff: Ein Angriff, der Geheimnisse aus dem physischen oder zeitlichen Verhalten einer Berechnung gewinnt – ihrer Ausführungszeit, ihren Cache-Zugriffen, ihrem Stromverbrauch, ihrer elektromagnetischen Abstrahlung oder ihrer Reaktion auf herbeigeführte Fehler – statt aus ihren Eingaben und Ausgaben.
Selbstsigniertes Zertifikat: Ein Zertifikat, dessen Aussteller und Subject identisch sind und dessen Signatur mit dem eigenen privaten Schlüssel erstellt wurde; ihm wird daher nur dort vertraut, wo es als Vertrauensanker installiert ist.
Seriennummer eines Zertifikats: Die positive Ganzzahl, pro Aussteller eindeutig und höchstens 20 Oktette lang, die ein Zertifikat in CRLs, OCSP-Anfragen und Vorfallsberichten identifiziert.
SHA-1: Die 160-Bit-Hashfunktion aus FIPS 180-1 (1995), deren Kollisionsresistenz heute in der Praxis gebrochen ist und die das NIST bis zum 31. Dezember 2030 für jeglichen kryptografischen Schutz ausmustert.
SHA-2: Die Familie von Hashfunktionen in FIPS 180-4 – SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 und SHA-512/256 –, von der NSA entworfen und 2001 veröffentlicht, heute fast überall die Standard-Hashfunktionen.
SHA-3: Die auf Keccak basierende Familie von Hashfunktionen aus FIPS 202 (2015) – SHA3-224, SHA3-256, SHA3-384, SHA3-512 und die Extendable-Output-Funktionen SHAKE128 und SHAKE256 –, aufgebaut auf einer Sponge-Konstruktion statt auf Merkle–Damgård.
SHA-256: Das 256-Bit-Mitglied der SHA-2-Familie (FIPS 180-4), Standard-Hashfunktion von TLS, JWT, X.509, Bitcoin und den meisten Tools zur Prüfung der Dateiintegrität, mit 128 Bit Kollisions- und 256 Bit Urbildresistenz.
SHAKE128 und SHAKE256: Die Extendable-Output-Funktionen (XOFs) aus FIPS 202, die aus dem Keccak-Sponge eine Ausgabe beliebiger gewünschter Länge erzeugen, bei ausreichend langer Ausgabe mit 128 Bit Sicherheit für SHAKE128 und 256 Bit für SHAKE256.
Shamir Secret Sharing: Adi Shamirs Verfahren von 1979, das ein Geheimnis per Zufallspolynom in n Anteile teilt: Beliebige k davon rekonstruieren es, k − 1 verraten gar nichts.
Shor-Algorithmus: Der Quantenalgorithmus von Peter Shor aus dem Jahr 1994, der ganze Zahlen faktorisiert und diskrete Logarithmen in Polynomialzeit berechnet; auf einem großen fehlertoleranten Quantencomputer würde er RSA, Diffie–Hellman, ECDSA, EdDSA und ECDH brechen.
Sicherheitsniveau (Bitsicherheit): Ein Maß für kryptografische Stärke, bei dem s Bit bedeuten, dass der beste bekannte Angriff etwa 2ˢ Operationen braucht; damit lassen sich Schlüssellängen verschiedener Algorithmen wie AES-128, P-256 und RSA-3072 vergleichen.
SIGHASH-Flags: Das an eine Bitcoin-Signatur angehängte Byte, das festlegt, welche Teile der Transaktion sie abdeckt: ALL (0x01), NONE (0x02), SINGLE (0x03), optional kombiniert mit ANYONECANPAY (0x80), dazu der Taproot-Standardwert 0x00.
Signatur-Malleability (Formbarkeit): Die Eigenschaft eines Signaturverfahrens oder seiner Kodierung, die es jedem erlaubt, eine gültige Signatur ohne Kenntnis des privaten Schlüssels in eine andere gültige Signatur für dieselbe Nachricht und denselben Schlüssel umzuwandeln.
signature_algorithms (TLS-Erweiterung): Die TLS-Erweiterung (13), in der ein Client oder Server die Signaturverfahren auflistet, die er akzeptiert, etwa ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256 und ed25519; signature_algorithms_cert (50) deckt Zertifikatssignaturen gesondert ab.
Signaturprüfung: Die Public-Key-Prüfung, ob eine Signatur über genau diese Nachricht mit dem privaten Schlüssel erzeugt wurde, der zu einem gegebenen öffentlichen Schlüssel gehört – mit einem Algorithmus, den der Verifizierer vorab gewählt hat.
Signieren von Git-Commits: Das Signieren von Git-Commits und -Tags mit Schlüsseln für OpenPGP, SSH (seit Git 2.34) oder X.509, damit Hosting-Plattformen und Reviewer prüfen können, wer sie erstellt hat; konfiguriert über gpg.format und user.signingkey.
Sigstore: Ein Open-Source-Signaturdienst, der ephemere Schlüssel für OIDC-Identitäten zertifiziert (Fulcio) und Signaturen öffentlich protokolliert (Rekor), sodass sich Artefakte ohne langfristige Schlüssel signieren und prüfen lassen.
SIWE (Sign-In with Ethereum): Das Nachrichtenformat nach ERC-4361 für die Anmeldung mit einem Ethereum-Konto: ein menschenlesbarer Text mit Domain, Adresse, URI, Version, Chain-ID, Nonce und Ausstellungszeitpunkt, signiert mit personal_sign.
SLH-DSA (FIPS 205): Der zustandslose hashbasierte Signaturalgorithmus (Stateless Hash-Based Digital Signature Algorithm) aus FIPS 205 (August 2024), abgeleitet von SPHINCS+, dessen Sicherheit allein auf Hashfunktionen beruht – um den Preis von Signaturen mit 7,8–50 KB und langsamem Signieren.
SLSA (Supply-chain Levels for Software Artifacts): Ein Framework der OpenSSF mit aufeinander aufbauenden Stufen für die Integrität von Build und Quellcode – Build L3 etwa bedeutet Provenance von einer gehärteten, isolierten Build-Plattform –, aktuell in der Spezifikation v1.2 (November 2025).
SNI (Server Name Indication): Die TLS-Erweiterung (RFC 6066 §3, Erweiterung 0), in der der Client den gewünschten Host nennt, sodass eine IP-Adresse viele Zertifikate ausliefern kann; sie wird im Klartext gesendet, sofern kein Encrypted Client Hello verwendet wird.
sntrup761x25519-sha512: Der SSH-Schlüsselaustausch, der Streamlined NTRU Prime sntrup761 mit X25519 kombiniert und mit SHA-512 hasht; in OpenSSH Standard ab Version 9.0 (2022), bis ihn mlkem768x25519-sha256 in 10.0 ablöste.
SPF (Sender Policy Framework): Die per DNS veröffentlichte Richtlinie nach RFC 7208, die festlegt, welche Hosts Mails mit einer Domain im SMTP-Envelope (MAIL FROM oder HELO) senden dürfen; Empfänger prüfen sie gegen die IP-Adresse der eingehenden Verbindung.
SPF-Lookup-Limit (10 Lookups): Die Regel aus RFC 7208, nach der die Auswertung eines SPF-Eintrags höchstens 10 Mechanismen und Modifikatoren mit DNS-Abfragen auslösen darf (include, a, mx, ptr, exists, redirect); darüber hinaus lautet das Ergebnis permerror.
SSH (Secure Shell): Das Protokoll nach RFC 4251–4254 für authentifizierte, verschlüsselte Fernanmeldung, Befehlsausführung, Dateiübertragung und Portweiterleitung, bei dem sich der Server mit einem Hostschlüssel ausweist und Benutzer sich mit Schlüsseln, Zertifikaten oder Passwörtern authentifizieren.
SSH-Hostschlüssel: Das langlebige Schlüsselpaar, mit dem ein SSH-Server jeden Schlüsselaustausch signiert und so seine Identität gegenüber Clients beweist, die den öffentlichen Schlüssel in known_hosts gespeichert haben oder einer CA vertrauen, die ihn zertifiziert hat.
SSH-Zertifikat: Eine OpenSSH-spezifische signierte Erklärung (kein X.509), in der der Schlüssel einer Zertifizierungsstelle den öffentlichen Schlüssel eines Benutzers oder Hosts an Principals, ein Gültigkeitsfenster und Optionen bindet, sodass einzelne Schlüssel nicht mehr verteilt werden müssen.
SSHSIG (SSH-Signaturen): Das Format von OpenSSH zum Signieren beliebiger Daten mit SSH-Schlüsseln (ssh-keygen -Y sign), das jede Signatur an einen Namespace bindet und die Grundlage für per SSH signierte Git-Commits und die Prüfung gegen eine Allowed-Signers-Datei bildet.
STARTTLS: Ein Protokollbefehl, der eine bestehende Klartextverbindung auf TLS umstellt – in SMTP (RFC 3207), IMAP, POP3, LDAP und XMPP – und für Downgrades anfällig ist, solange keine Richtlinie TLS vorschreibt.
Subject Alternative Name (SAN): Die X.509-Erweiterung (OID 2.5.29.17), die die DNS-Namen, IP-Adressen, E-Mail-Adressen oder URIs auflistet, für die ein Zertifikat gültig ist, und das einzige Feld, mit dem Browser den Hostnamen eines Servers abgleichen.
SubjectPublicKeyInfo (SPKI): Die ASN.1-Struktur aus RFC 5280, die einen Algorithmusbezeichner mit den Bits des öffentlichen Schlüssels verbindet; sie steckt in jedem X.509-Zertifikat und ist das Standard-Dateiformat für öffentliche Schlüssel (-----BEGIN PUBLIC KEY-----).

T

Taproot: Der Bitcoin-Soft-Fork aus BIP-340, BIP-341 und BIP-342, aktiviert bei Block 709.632 am 14. November 2021, der Schnorr-Signaturen und P2TR-Ausgaben einführte, die sich auf einen Schlüssel und einen optionalen Baum von Skripten festlegen.
TLS (Transport Layer Security): Das IETF-Protokoll, das einen Server (und optional einen Client) authentifiziert und einen Bytestrom zwischen beiden verschlüsselt; HTTPS, E-Mail, APIs und die meisten anderen Internetprotokolle nutzen es. Die aktuelle Version ist 1.3.
TLS 1.2: Die TLS-Version von 2008 (RFC 5246), die noch breit unterstützt wird; sie führte AEAD-Cipher-Suites und SHA-256 ein, braucht aber zwei Roundtrips und erlaubt schwache Optionen, die TLS 1.3 entfernt hat.
TLS 1.3: Die aktuelle Version von TLS, 2018 als RFC 8446 veröffentlicht und 2026 als RFC 9846 überarbeitet, mit einem Handshake in einem Roundtrip, verpflichtender Forward Secrecy, ausschließlich AEAD-Cipher-Suites und verschlüsseltem Handshake.
TLS-Handshake: Der einleitende Nachrichtenaustausch einer TLS-Verbindung, in dem sich Client und Server auf Parameter einigen, einen Schlüsselaustausch durchführen, sich authentifizieren (in der Regel der Server über sein Zertifikat) und die Traffic-Schlüssel ableiten.
TLS-Session-Resumption (Sitzungswiederaufnahme): Das Wiederaufnehmen einer TLS-Sitzung mit Secrets einer früheren Verbindung, das die Authentifizierung per Zertifikat überspringt, Rechenaufwand spart und unter TLS 1.3 auch 0-RTT-Daten transportieren kann.
TLS-Zertifikatskompression: Die Erweiterung von TLS 1.3 aus RFC 8879 (compress_certificate, 27), mit der der Server seine Zertifikatskette mit zlib, brotli oder zstd komprimieren kann; typischerweise schrumpft sie dabei um ein Drittel oder mehr.
Trusted Publishing: Das Veröffentlichen von Paketen in einer Registry aus der CI mit kurzlebigen Zugangsdaten auf OIDC-Basis statt eines langlebigen API-Tokens; eingeführt von PyPI im April 2023 und angeboten von npm (allgemein verfügbar seit Juli 2025), RubyGems, crates.io und anderen.
TUF (The Update Framework): Eine Spezifikation für sichere Software-Updates, seit 2019 ein Graduated-Projekt der CNCF, die das Signieren auf die Rollen root, targets, snapshot und timestamp mit Schwellenwerten und Ablaufdaten aufteilt, damit das System eine Schlüsselkompromittierung übersteht.
typ (JOSE-Header für den Typ): Der JOSE-Header-Parameter, der den Medientyp des gesamten Tokens angibt, etwa JWT, at+jwt, dpop+jwt oder kb+jwt; er dient der expliziten Typisierung, damit sich eine Art von Token nicht durch eine andere ersetzen lässt.

V

Verifiable Credential: Ein manipulationserkennbarer Satz von Claims über ein Subject, signiert von einem Aussteller und vom Subject in einer Wallet verwahrt; ein Verifizierer kann ihn prüfen, ohne den Aussteller zu kontaktieren. Es gibt mehrere standardisierte Formate (W3C VC, SD-JWT VC, mdoc).
Vertrauenswürdige Zeitstempel (RFC 3161): Das Einholen eines signierten Tokens bei einem Zeitstempeldienst: Das Token bindet einen Hash von Daten an einen vertrauenswürdigen Zeitpunkt, sodass sich zeigen lässt, dass eine Signatur vor dem Ablauf oder Widerruf eines Zertifikats entstand.
VMC (Verified Mark Certificate): Ein X.509-Zertifikat, das eine Domain für BIMI an ein eingetragenes Markenlogo bindet, nach einer Prüfung von Marke und Identität ausgestellt wird und das SVG-Logo in einer Logotype-Erweiterung enthält.

W

Web Bot Auth: Eine IETF-Initiative auf Basis von HTTP Message Signatures, mit der automatisierte Clients wie Crawler und KI-Agenten ihre Anfragen mit einem veröffentlichten Schlüssel signieren, damit Websites sie zuverlässig identifizieren können, statt User-Agent-Strings oder IP-Bereichen zu vertrauen.
Web of Trust: Das dezentrale Vertrauensmodell von OpenPGP, in dem Benutzer einander die Schlüssel beglaubigen und jeder selbst entscheidet, wie weit er Beglaubigenden vertraut, statt sich auf Zertifizierungsstellen zu verlassen.
WebAuthn (Web Authentication): Die Browser-API des W3C (navigator.credentials.create und get mit den Optionen unter publicKey), über die Websites Public-Key-Credentials auf Authenticators registrieren und nutzen; Level 3 wurde am 25. August 2026 zur W3C-Empfehlung.
Wildcard-Zertifikat: Ein Zertifikat mit einem Subject Alternative Name wie *.example.com, der an dieser Stelle auf genau ein beliebiges Label passt, etwa auf www.example.com, aber weder auf example.com noch auf a.b.example.com.
WKD (Web Key Directory): Ein Verfahren, OpenPGP-Schlüssel auf der eigenen Domain unter /.well-known/openpgpkey/ zu veröffentlichen, damit Mail-Clients den Schlüssel zu einer E-Mail-Adresse über HTTPS abrufen können (draft-koch-openpgp-webkey-service).

X

X.509: Das Zertifikatsformat der ITU-T, für das Internet durch RFC 5280 profiliert, das einen öffentlichen Schlüssel unter der Signatur einer ausstellenden Zertifizierungsstelle an den Namen des Subjects und an Erweiterungen bindet.
x5c (Header mit X.509-Zertifikatskette): Der Parameter im JOSE-Header und im JWK, der eine X.509-Zertifikatskette als Array base64-kodierter (nicht base64url-kodierter) DER-Zertifikate trägt; das erste enthält den Signaturschlüssel.
X25519: Die in RFC 7748 definierte Diffie-Hellman-Funktion auf Curve25519 mit 32-Byte-Schlüsseln und einem gemeinsamen Geheimnis von 32 Byte, genutzt für den Schlüsselaustausch in TLS 1.3, SSH, WireGuard, Signal und age.
X25519MLKEM768: Die Gruppe 0x11EC (RFC 10024) für hybriden Schlüsselaustausch in TLS 1.3 aus ML-KEM-768 und X25519, Post-Quanten-Standard in aktuellen Browsern, OpenSSL und Go.
XAdES: Das ETSI-Format für fortgeschrittene elektronische Signaturen in XML (EN 319 132), das XML-DSig um signierte Eigenschaften wie Signaturzeitpunkt und Digest des Zertifikats sowie um die Langzeitstufen B-T, B-LT und B-LTA erweitert.
XML-Signatur (XML-DSig): Der W3C-Standard zum Signieren von XML (XML Signature Syntax and Processing 1.1, 2013), bei dem ein Element ds:Signature die signierten Daten per URI referenziert, kanonisiert und einen SignedInfo-Block aus Digests signiert.
XML-Signature-Wrapping (XSW): Eine Klasse von Angriffen auf XML-signierte Nachrichten, bei denen ein Angreifer das signierte Element verschiebt und ein gefälschtes einfügt, sodass die Signatur für das Original weiterhin erfolgreich geprüft wird, während die Anwendung die Fälschung verarbeitet.
XMSS und XMSS^MT: Das eXtended Merkle Signature Scheme aus RFC 8391 und NIST SP 800-208, eine zustandsbehaftete hashbasierte Signatur auf Basis von WOTS+-Einmalschlüsseln, mit einer Multi-Tree-Variante für mehr Signaturkapazität.
xpub (erweiterter öffentlicher Schlüssel): Ein erweiterter öffentlicher Schlüssel nach BIP-32 – öffentlicher Schlüssel plus Chain Code –, aus dem sich jeder nicht gehärtete öffentliche Kindschlüssel und jede Adresse darunter ableiten lässt; genutzt von Watch-only-Wallets und Zahlungsservern.

Z

Zertifikat (Public-Key-Zertifikat): Eine signierte Aussage eines Ausstellers, dass ein bestimmter öffentlicher Schlüssel zu einem benannten Subject gehört, gültig für eine begrenzte Zeit und für festgelegte Zwecke, meist im Format X.509.
Zertifikats- oder Public-Key-Pinning: Das Beschränken der Zertifikate oder öffentlichen Schlüssel, die ein Client für einen Host akzeptiert, auf eine feste Menge – über die gewöhnliche Kettenvalidierung hinaus –, indem er Hashes eines CA-Schlüssels, eines Zwischenzertifikats oder des eigenen Schlüssels des Servers abgleicht.
Zertifikatskette: Die geordnete Folge von Zertifikaten vom End-Entity-Zertifikat (Leaf-Zertifikat) über ein oder mehrere Zwischenzertifikate bis zu einem vertrauenswürdigen Root-Zertifikat, wobei jedes vom jeweils nächsten signiert ist.
Zertifikatslaufzeit (Gültigkeitszeitraum): Die Zeitspanne von notBefore bis notAfter eines Zertifikats, beide eingeschlossen; für öffentlich vertrauenswürdige TLS-Zertifikate liegt das Maximum seit dem 15. März 2026 bei 200 Tagen und sinkt 2027 auf 100 Tage und 2029 auf 47 Tage.
Zertifizierungspfadvalidierung: Der Algorithmus aus RFC 5280 §6, der entscheidet, ob eine Kette von einem Vertrauensanker bis zu einem End-Entity-Zertifikat gültig ist, und dabei Signaturen, Gültigkeitszeiträume, Namen, Einschränkungen, Richtlinien und Widerruf prüft.
Zwischen-CA (Intermediate CA): Ein CA-Zertifikat, von einer Root- oder anderen Zwischen-CA signiert, dessen Schlüssel End-Entity-Zertifikate ausstellt; so bleibt der Root-Schlüssel offline.

#

0-RTT (TLS Early Data): Die Funktion von TLS 1.3, mit der ein Client bei der Wiederaufnahme einer Sitzung schon im ersten Flight Anwendungsdaten senden kann, verschlüsselt mit einem Schlüssel aus einer früheren Sitzung – auf Kosten von Replay-Schutz und Forward Secrecy für diese Daten.

Glossar

A bis Z

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

Ö

P

Q

R

S

T

V

W

X

Z

#

Nach Thema

Signaturen · 52 Begriffe

JOSE und JWT · 39 Begriffe

PKI und Zertifikate · 69 Begriffe

TLS · 65 Begriffe

E-Mail · 18 Begriffe

Web3 · 33 Begriffe

Post-Quanten-Kryptografie · 34 Begriffe

Identität und WebAuthn · 53 Begriffe

Lieferkette · 30 Begriffe

OpenPGP · 9 Begriffe

Mathematik · 48 Begriffe