Kryptographie: Verschlüsselung, Algorithmen, PKI und Post-Quantum

Ohne Kryptographie gibt es keine IT-Sicherheit. HTTPS, Passwort-Hashing, digitale Signaturen, Ende-zu-Ende-Verschlüsselung - all das basiert auf kryptographischen Algorithmen. "Die Verschlüsselung ist sicher" ist in der Informatik eine der häufigsten Fehlannahmen: Die Mathematik hinter AES, RSA oder ECC ist oft tatsächlich sicher. Das Problem liegt in der Implementierung: falsche Modi, schwache Schlüssel, unsichere Zufallszahlen, falsche Padding-Verfahren.

Die drei kryptographischen Grundprobleme

Kryptographie löst drei fundamentale Sicherheitsprobleme:

1. Vertraulichkeit: Nur Berechtigte können Daten lesen (Verschlüsselung)
2. Integrität: Daten können nicht unbemerkt verändert werden (Hash-Funktionen, MAC)
3. Authentizität: Die Identität des Absenders ist beweisbar (Digitale Signaturen, Zertifikate)

Symmetrische Kryptographie verwendet denselben Schlüssel für Ver- und Entschlüsselung. Sie ist schnell und effizient, aber das Schlüsselaustausch-Problem - wie überträgt man den geheimen Schlüssel sicher? - bleibt ungelöst. Anwendung: Datenverschlüsselung (AES, ChaCha20).

Asymmetrische Kryptographie (Public-Key) nutzt ein Schlüsselpaar aus öffentlichem und privatem Schlüssel. Sie ist langsamer als symmetrische Verfahren, löst aber das Schlüsselaustausch-Problem. Anwendung: TLS-Handshake, digitale Signaturen, E-Mail-Verschlüsselung.

Hashfunktionen sind Einwegfunktionen, die beliebige Daten auf eine feste Ausgabelänge komprimieren. Sie müssen kollisionsresistent sein: keine zwei verschiedenen Eingaben sollen denselben Hash ergeben. Anwendung: Passwort-Speicherung, Integritätsprüfung, Signaturen.

Symmetrische Verschlüsselung

Bei der symmetrischen Verschlüsselung nutzen Sender und Empfänger denselben Schlüssel zum Ver- und Entschlüsseln.

Vorteil: Sehr schnell, effizient für große Datenmengen. Nachteil: Schlüsselaustausch-Problem - wie überträgt man den geheimen Schlüssel sicher?

AES (Advanced Encryption Standard)

AES ist der weltweite Standard für symmetrische Verschlüsselung und existiert in drei Schlüssellängen: AES-128 (128 Bit, ausreichend für die meisten Anwendungen bis ~2030), AES-192 (192 Bit, selten genutzt) und AES-256 (256 Bit, empfohlen für hochsensible Daten und Post-Quantum-sicherer).

Der gewählte Block-Modus entscheidet über die praktische Sicherheit:

ECB (Electronic Codebook) - niemals verwenden: Gleicher Plaintext ergibt immer gleichen Ciphertext, sodass Muster im Klartext im Ciphertext sichtbar bleiben. Das berühmte Beispiel: Ein mit ECB verschlüsseltes Tux-Bild bleibt erkennbar.

CBC (Cipher Block Chaining) - veraltet, fehleranfällig: Der IV muss zufällig und einmalig sein. CBC ist anfällig für Padding Oracle Attacks (POODLE, Lucky Thirteen) und sollte für neue Implementierungen nicht mehr verwendet werden.

CTR (Counter Mode) - gut, aber ohne Authentifizierung: Verwandelt einen Block-Cipher in einen Stream-Cipher. Die Nonce muss zwingend einmalig sein (Nonce-Reuse ist katastrophal). Da keine Integritätsprüfung integriert ist, bleibt Man-in-the-Middle möglich.

GCM (Galois/Counter Mode) - empfohlen: Bietet authentifizierte Verschlüsselung (AEAD) und kombiniert Vertraulichkeit mit Integrität. Die Nonce muss einmalig sein (96 Bit empfohlen). Standard für TLS 1.3, Signal und WireGuard. Warnung: Wird eine Nonce zweimal verwendet, ist vollständige Entschlüsselung möglich.

ChaCha20-Poly1305: Alternative zu AES-GCM, besonders auf Systemen ohne AES-Hardware-Beschleunigung (IoT). In TLS 1.3 und dem Signal Protocol verwendet.

SIV (Synthetic IV): Für deterministische Verschlüsselung geeignet, wenn dieselben Daten immer dasselbe Ergebnis erzeugen müssen (z.B. suchbare Verschlüsselung). Nonce-Reuse-resistent.

Veraltete/unsichere Algorithmen - nicht mehr verwenden:

• DES / 3DES - Schlüssellänge zu kurz (56 Bit), praktisch gebrochen
• RC4 - schwere Schwächen bekannt, in TLS verboten

# AES-256-GCM in Python (korrekte Verwendung)
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

def encrypt(key: bytes, plaintext: bytes) -> tuple[bytes, bytes]:
    """Verschlüsselt mit AES-256-GCM. Gibt (nonce, ciphertext) zurück."""
    aesgcm = AESGCM(key)
    nonce = os.urandom(12)  # 12 Byte Nonce für GCM (NIE wiederverwenden!)
    ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=None)
    return nonce, ciphertext

def decrypt(key: bytes, nonce: bytes, ciphertext: bytes) -> bytes:
    """Entschlüsselt und prüft Integrität automatisch (AuthTag)."""
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(nonce, ciphertext, associated_data=None)

# Schlüssel generieren (32 Byte = 256 Bit)
key = os.urandom(32)
nonce, ct = encrypt(key, b"Geheime Nachricht")
plaintext = decrypt(key, nonce, ct)

// Node.js (crypto built-in) - AES-256-GCM
const crypto = require('crypto');
const algorithm = 'aes-256-gcm';

function encrypt(plaintext, key) {
  const nonce = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv(algorithm, key, nonce);
  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final()
  ]);
  const tag = cipher.getAuthTag();  // Authentifizierungs-Tag!
  return { nonce, encrypted, tag };
}

function decrypt(nonce, encrypted, tag, key) {
  const decipher = crypto.createDecipheriv(algorithm, key, nonce);
  decipher.setAuthTag(tag);         // Tag MUSS geprüft werden!
  return Buffer.concat([
    decipher.update(encrypted),
    decipher.final()
  ]).toString('utf8');
}

Asymmetrische Verschlüsselung (Public-Key-Kryptographie)

Bei der asymmetrischen Verschlüsselung gibt es ein Schlüsselpaar:

• Public Key: Öffentlich - jeder darf ihn kennen und damit verschlüsseln
• Private Key: Geheim - nur der Eigentümer hat ihn, nur er kann entschlüsseln

Das Geniale: Beide Schlüssel sind mathematisch verbunden, aber aus dem Public Key kann man den Private Key nicht in annehmbarer Zeit berechnen.

RSA

RSA basiert auf der Schwierigkeit, große Zahlen zu faktorisieren. Schlüssellängen nach BSI TR-02102 (2024): RSA-1024 ist gebrochen und darf nicht mehr verwendet werden. RSA-2048 ist das Minimum und akzeptabel bis ~2030. RSA-3072 wird bis 2030+ empfohlen. RSA-4096 ist langfristig sicher, aber für TLS sollte ECDSA vorgezogen werden.

Anwendungen: digitale Signaturen (Code Signing, PDF-Signatur, PKI-Zertifikate) und Key Encapsulation in TLS (wird durch ECDH ersetzt).

Das RSA Padding ist sicherheitskritisch: PKCS#1 v1.5 ist veraltet und anfällig für den Bleichenbacher-Angriff. Für Verschlüsselung wird OAEP (Optimal Asymmetric Encryption Padding) empfohlen, für Signaturen PSS (Probabilistic Signature Scheme).

# Python - RSA-Verschlüsselung mit OAEP
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import hashes

ciphertext = public_key.encrypt(
    plaintext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

ECC (Elliptic Curve Cryptography)

ECC bietet gleiche Sicherheit wie RSA bei deutlich kleineren Schlüsseln: RSA-3072 entspricht ECDSA-P256, RSA-7680 entspricht ECDSA-P384. ECC ist 10-100x schneller und benötigt weniger Rechenaufwand - ideal für mobile Geräte und IoT.

Die wichtigsten Kurven: P-256 (secp256r1) ist die Standardkurve für TLS, FIDO2, Code Signing und wird von Apple und Google genutzt (BSI: "ausreichend sicher"). P-384 (secp384r1) bietet höhere Sicherheit und wird für staatliche Systeme empfohlen. Curve25519 (Ed25519 / X25519) von Daniel Bernstein liegt außerhalb der NIST-Spezifikation und gilt als besonders vertrauenswürdig - Standard in Signal, WireGuard und SSH-Schlüsseln. Empfehlung für neue Systeme.

Anwendungen: ECDSA für digitale Signaturen (TLS, Bitcoin), ECDH für Key Agreement, EdDSA für moderne Signaturen (Ed25519, Ed448).

# Ed25519 SSH-Key generieren (deutlich besser als RSA-2048 default)
ssh-keygen -t ed25519 -C "user@firma.de"

# ECDH Key Exchange (Python)
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey

alice_private = X25519PrivateKey.generate()
alice_public = alice_private.public_key()
bob_private = X25519PrivateKey.generate()
bob_public = bob_private.public_key()

# Key Exchange: beide leiten denselben Shared Secret ab
alice_shared = alice_private.exchange(bob_public)
bob_shared = bob_private.exchange(alice_public)
assert alice_shared == bob_shared  # True! Ohne dass Private Keys übertragen wurden

# Ed25519 für Signaturen:
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
private_key = Ed25519PrivateKey.generate()
public_key = private_key.public_key()
signature = private_key.sign(message)
public_key.verify(signature, message)  # Exception wenn ungültig

Diffie-Hellman / ECDH

Ein Schlüsselaustausch-Protokoll, kein Verschlüsselungsalgorithmus. Ermöglicht sicheren Schlüsselaustausch über unsicheren Kanal.

Perfect Forward Secrecy (PFS): Ephemeral Diffie-Hellman - jede Session hat eigene Schlüssel. Kompromittierung des Long-Term Keys gefährdet vergangene Sessions nicht.

Hash-Funktionen

Eine kryptographische Hash-Funktion transformiert beliebig große Eingaben in einen Fingerabdruck fester Länge:

Beispiel: Die Eingabe "Hallo" ergibt den SHA-256-Hash 185f8db32921bd46d35..., während "Hallo!" (eine Änderung!) den völlig anderen Hash d9414818c6cde70b1e2... liefert. Selbst das komplette Faust-Epos ergibt einen Hash identischer Länge.

Eigenschaften:

• Determinismus: Gleiche Eingabe → immer gleicher Hash
• Einwegfunktion: Aus dem Hash kann die Eingabe nicht rekonstruiert werden
• Kollisionsresistenz: Praktisch unmöglich, zwei verschiedene Eingaben mit gleichem Hash zu finden
• Lawineneffekt: Kleinste Änderung der Eingabe → komplett anderer Hash

Algorithmus	Ausgabelänge	Status
MD5	128 Bit	Gebrochen - Kollisionen bekannt, niemals für Sicherheit verwenden!
SHA-1	160 Bit	Gebrochen - Google SHAttered 2017 ("Shattered"-Angriff: zwei PDFs mit gleichem SHA-1)
SHA-256	256 Bit	Sicher, Standard, empfohlen
SHA-384	384 Bit	Sicher, höherer Schutzbedarf
SHA-512	512 Bit	Sicher, höherer Schutzbedarf
SHA-3 / Keccak	variabel	Sicher, andere Konstruktion (Sponge-Funktion) - Backup falls SHA-2 kompromittiert
Blake2 / Blake3	variabel	Sehr schnell, sicher; gut für Checksums

Anwendungen: Datei-Integrität, Download-Prüfsummen, HMAC, digitale Signaturen (Hash wird signiert, nicht das Dokument), Git-Commit-IDs.

Passwort-Hashing

Kryptographische Hashes wie SHA-256 sind zu schnell für Passwörter. Eine RTX 4090 kann 100+ Milliarden SHA-256-Hashes pro Sekunde berechnen. Stattdessen: Passwort-spezifische Algorithmen mit eingebautem "Work Factor":

Passwörter niemals als MD5 oder SHA-256 speichern: Ohne Salt knacken Rainbow Tables in Sekunden, mit Salt aber schnellem Hash ermöglicht GPU-Cracking die Attacke.

Korrekte Passwort-Hash-Algorithmen: bcrypt nutzt einen Cost Factor (2^cost Iterationen), ist auf 72 Byte begrenzt, alt aber solide - Cost Factor 12 als Minimum für neue Anwendungen. scrypt ist memory-hard, ressourcenintensiver und NIST SP 800-132-kompatibel. Argon2id ist die OWASP-Empfehlung (2024) und PHC-Gewinner mit drei Varianten: Argon2d (GPU-resistant), Argon2i (Timing-safe) und Argon2id (beide). PBKDF2 ist FIPS-140-konform und gut für Compliance-Anforderungen; mindestens 600.000 Iterationen für SHA-256 (OWASP 2023).

OWASP-Parameter für Argon2id: 64 MB Speicher minimum (m=65536), 3 Iterationen minimum (t=3), Anzahl CPU-Kerne als Thread-Zahl (p=4).

# Argon2id (Python - argon2-cffi)
from argon2 import PasswordHasher

ph = PasswordHasher(
    time_cost=3,       # Iterationen
    memory_cost=65536, # 64 MB
    parallelism=4,     # 4 Threads
    hash_len=32,       # 256-Bit Output
    salt_len=16        # 128-Bit Salt
)

hash = ph.hash("MeinPasswort123!")

try:
    ph.verify(hash, "MeinPasswort123!")  # True
    if ph.check_needs_rehash(hash):
        hash = ph.hash("MeinPasswort123!")  # Upgrade bei neuen Params
except VerifyMismatchError:
    print("Falsches Passwort!")

Message Authentication Code (MAC)

Ein MAC kombiniert eine Nachricht mit einem geheimen Schlüssel zu einem Integritätsnachweis:

Der MAC wird berechnet als HMAC(Schlüssel, Nachricht).

Empfänger berechnet MAC neu und vergleicht - stimmt er überein, ist die Nachricht unverändert und kommt von jemandem mit dem Schlüssel. Anwendung: API-Signaturen (HMAC-SHA256 bei OAuth, JWT), TLS Record-Layer.

Digitale Signaturen

Digitale Signaturen nutzen asymmetrische Kryptographie für Authentizität und Nicht-Abstreitbarkeit:

Beim Signieren wird Hash(Dokument) mit dem Private Key verschlüsselt, um die Signatur zu erzeugen. Beim Verifizieren wird geprüft, ob Hash(Dokument) mit dem durch den Public Key entschlüsselten Signatur-Hash übereinstimmt.

Verwendung: Code Signing, E-Mail-Signaturen (S/MIME, PGP), TLS-Zertifikate, DKIM.

# GPG Signatur für Software-Release
gpg --armor --detach-sign myapp-1.2.3-linux.tar.gz
# → myapp-1.2.3-linux.tar.gz.asc (Signatur)

# Verifizierung durch Nutzer
gpg --verify myapp-1.2.3-linux.tar.gz.asc myapp-1.2.3-linux.tar.gz

# Windows Code Signing (signtool)
signtool sign /fd SHA256 /tr http://timestamp.digicert.com \
  /td SHA256 /f mycert.pfx /p password myapp.exe

Public Key Infrastructure (PKI)

Das Problem: Wem gehört ein Public Key? Woher weiß ich, dass der Public Key der "Deutschen Bank" wirklich von der Deutschen Bank ist?

PKI-Lösung: Eine vertrauenswürdige Certificate Authority (CA) stellt digitale Zertifikate aus, die Public Keys mit Identitäten verknüpfen und mit dem CA-Schlüssel signieren.

Die PKI-Hierarchie ist dreistufig: Die Root CA ist selbst-signiert, offline und im HSM gesperrt. Sie signiert Intermediate CAs, die wiederum die End-Entity-Zertifikate ausstellen: Webserver-Zertifikate (TLS), Code-Signing-Zertifikate, E-Mail-Zertifikate (S/MIME) und Client-Zertifikate (mTLS).

Die Root CA wird offline gehalten, weil ihre Kompromittierung alle ausgestellten Zertifikate ungültig machen würde. Sie wird nur verwendet, um neue Intermediate CAs auszustellen.

TLS-Ablauf (vereinfacht):

1. Browser ruft https://bank.de auf
2. Server sendet Zertifikat
3. Browser prüft: Zertifikat gültig? Von vertrauenswürdiger CA signiert? Für bank.de ausgestellt?
4. Browser und Server handeln Sitzungsschlüssel aus (ECDHE)
5. Alle weiteren Kommunikation AES-256-GCM verschlüsselt

Zertifikatstypen:

• DV (Domain Validation): Nur Domain-Kontrolle bestätigt - für kleine Websites
• OV (Organization Validation): Organisation wird überprüft - für Unternehmen
• Wildcard: *.example.com - gilt für alle Subdomains
• SAN (Subject Alternative Names): Mehrere Domains in einem Zertifikat

Certificate Transparency (CT): Alle TLS-Zertifikate müssen in öffentliche CT-Logs eingetragen werden. Monitoring via crt.sh.

TLS - Transport Layer Security

TLS-Versionen im Überblick: SSL 2.0/3.0 und TLS 1.0 (POODLE, BEAST) und TLS 1.1 (seit 2020 abgekündigt) sind veraltet und dürfen nicht verwendet werden. TLS 1.2 ist akzeptabel mit sicheren Cipher Suites. TLS 1.3 ist empfohlen.

TLS 1.3 bringt wichtige Verbesserungen: Forward Secrecy ist immer aktiv (ECDHE/DHE zwingend), kein RSA-Key-Transport mehr, schwache Cipher Suites wie RC4, 3DES, MD5 und SHA1 wurden entfernt. Der Handshake erfolgt in 1-RTT statt 2-RTT (schneller), und 0-RTT Resumption ist möglich (Replay-Angriff-Risiko beachten).

TLS 1.3 erlaubt nur noch fünf Cipher Suites: TLS_AES_256_GCM_SHA384 und TLS_CHACHA20_POLY1305_SHA256 (beide empfohlen), TLS_AES_128_GCM_SHA256 (Minimum) sowie zwei IoT-Varianten. Für TLS 1.2 sind sichere Suites: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384 und ECDHE-ECDSA-AES128-GCM-SHA256. Unsichere TLS-1.2-Suites sind CBC-basierte (Padding Oracle), Suites ohne das "E" in DHE/ECDHE (kein Forward Secrecy) und alle RC4-Suites.

# Nginx - TLS 1.3 + sichere Header
ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers off;  # Client bestimmt Cipher in TLS 1.3
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384';
ssl_ecdh_curve X25519:secp384r1;
ssl_session_tickets off;        # Session Tickets deaktivieren (PFS!)

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Content-Type-Options nosniff;

TLS prüfen: testssl.sh --full https://firma.de oder online über ssllabs.com/ssltest (gibt Note A bis F).

BSI-Empfehlung (TR-02102-2):

• TLS 1.3 bevorzugen, TLS 1.2 akzeptabel
• TLS 1.0 und 1.1 deaktivieren
• Sichere Cipher Suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256

Post-Quantum-Kryptographie

Shor's Algorithmus kann RSA und ECC auf einem ausreichend leistungsfähigen Quantencomputer in polynomieller Zeit knacken. RSA-2048 würde in Stunden oder Tagen fallen statt in Milliarden Jahren.

Das "Harvest Now, Decrypt Later"-Problem: Gegner sammeln heute verschlüsselte Kommunikation und entschlüsseln sie, sobald Quantencomputer verfügbar sind. Zeitrahmen für kryptographisch relevante Quantencomputer: ca. 2030-2035. Für langfristig sensible Daten sollte PQC jetzt evaluiert werden.

Die 2024 finalisierten NIST PQC Standards: ML-KEM (CRYSTALS-Kyber) als Key Encapsulation Mechanism ersetzt RSA/ECDH in TLS. ML-DSA (CRYSTALS-Dilithium) für digitale Signaturen ersetzt RSA/ECDSA. SLH-DSA (SPHINCS+) bietet hash-basierte Signaturen als konservativen Backup.

BSI-Empfehlung (TR-02102-1): Ab 2025 hybride Kryptographie (klassisch + PQC), spätestens 2030 Migration auf PQC abschließen. Für klassifizierte Daten gilt hybride Kryptographie sofort. Crypto-Agility als Designprinzip: Algorithmen müssen austauschbar sein.

TLS 1.3 mit PQC wird bereits unterstützt: Die hybride Kurve X25519MLKEM768 (X25519 + ML-KEM-768) ist ab Chrome 131 und Firefox 132 aktiv. OpenSSH nutzt ab Version 9.0 hybriden ECDH + Kyber.

BSI-Empfehlungen für Algorithmen und Schlüssellängen

Das BSI veröffentlicht regelmäßig die Technische Richtlinie TR-02102 mit konkreten Empfehlungen:

Verfahren	Empfehlung	Mindestschlüssellänge
Symmetrisch (AES)	Empfohlen	AES-128 (normal), AES-256 (erhöht)
Hash	SHA-256 aufwärts	256 Bit
RSA	Akzeptabel	2000 Bit (bis 2026), 3000 Bit danach
ECDH/ECDSA	Empfohlen	256 Bit (P-256 oder Brainpool)
Post-Quantum	Empfohlen für neue Systeme	ML-KEM-768+

Häufige Implementierungsfehler

Fehler 1: Eigene Kryptographie entwickeln. Eigene Implementierungen von Krypto-Primitiven sind fast immer fehlerhaft. Stattdessen etablierte Bibliotheken verwenden (OpenSSL, libsodium, cryptography).

Fehler 2: Veraltete Algorithmen. MD5, SHA-1, DES, 3DES und RC4 sind gebrochen oder zu schwach. TLS 1.0 und 1.1 müssen deaktiviert werden.

Fehler 3: Schlechte Schlüsselverwaltung. Hardcoded Keys im Source Code, derselbe Schlüssel für Verschlüsselung und Signatur, oder nie rotierte Schlüssel sind kritische Risiken. Lösung: HSM, HashiCorp Vault, AWS KMS oder Azure Key Vault.

Fehler 4: Falsches Passwort-Hashing. MD5 oder SHA-1 mit oder ohne Salt sowie PBKDF2 mit zu wenig Iterationen sind unzureichend. Lösung: Argon2id mit OWASP-Parametern.

Fehler 5: Nonce/IV-Wiederverwendung. Eine in AES-GCM zweimal verwendete Nonce ermöglicht vollständige Entschlüsselung. Lösung: os.urandom() für jeden Verschlüsselungsvorgang.

Fehler 6: Side-Channel-Angriffe ignorieren. Einfache String-Vergleiche bei kryptographischen Tokens ermöglichen Timing-Angriffe. Falsch: if stored_token == provided_token. Richtig: hmac.compare_digest(stored_token, provided_token).

Fehler 7: Zufallszahlen-Fehler. random.random() (Python), Math.random() (Java/JS) sind nicht kryptographisch sicher. Korrekte Alternativen: secrets.token_bytes(32) (Python), SecureRandom.getInstanceStrong() (Java), crypto.randomBytes(32) (Node.js), crypto/rand.Read() (Go).

Fazit

Kryptographie ist das Fundament jeder IT-Sicherheitsarchitektur. Ohne korrekt implementierte Verschlüsselung sind selbst perfekt konfigurierte Firewalls und Zugangssysteme wirkungslos, wenn die übertragenen oder gespeicherten Daten im Klartext vorliegen. Die wichtigsten praktischen Konsequenzen: TLS 1.3 überall, AES-256-GCM für Datenspeicherung, SHA-256 für Integrität, Argon2id für Passwörter - und eine frühzeitige Planung der Migration zu Post-Quantum-Kryptographie.