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)

Die drei Säulen der Kryptographie:

Symmetrische Kryptographie:
  → Gleicher Schlüssel für Ver- und Entschlüsselung
  → Schnell, aber Schlüsselaustausch ist das Problem
  → Anwendung: Datenverschlüsselung (AES, ChaCha20)

Asymmetrische Kryptographie (Public-Key):
  → Schlüsselpaar: Public Key (öffentlich) + Private Key (geheim)
  → Langsamer, aber löst Schlüsselaustausch-Problem
  → Anwendung: TLS-Handshake, digitale Signaturen, E-Mail-Verschlüsselung

Hashfunktionen:
  → Einwegfunktion: aus beliebigen Daten → feste Länge
  → Kollisionsresistent: keine zwei Eingaben sollen denselben Hash haben
  → 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.

Schlüssellängen:
  AES-128: 128 Bit - ausreichend für die meisten Anwendungen (bis ~2030)
  AES-192: 192 Bit - selten genutzt
  AES-256: 256 Bit - empfohlen für hochsensible Daten, Post-Quantum-sicherer

Block-Modi - entscheidend für Sicherheit:

ECB (Electronic Codebook) - NIEMALS VERWENDEN:
  → Gleicher Plaintext → gleicher Ciphertext (deterministisch)
  → Muster im Klartext sichtbar im Ciphertext!
  → Berühmtes Beispiel: verschlüsseltes Tux-Bild bleibt erkennbar

CBC (Cipher Block Chaining) - veraltet, fehleranfällig:
  → IV (Initialization Vector) muss zufällig und einmalig sein
  → Anfällig für Padding Oracle Attacks (POODLE, Lucky Thirteen)
  → Nicht empfohlen für neue Implementierungen

CTR (Counter Mode) - gut, aber ohne Authentifizierung:
  → Verwandelt Block-Cipher in Stream-Cipher
  → Nonce MUSS einmalig sein (Nonce-Reuse = katastrophal!)
  → Keine Integritätsprüfung → Man-in-the-Middle möglich

GCM (Galois/Counter Mode) - EMPFOHLEN:
  → Authentifizierte Verschlüsselung: AEAD (Encryption + Integrity)
  → Nonce MUSS einmalig sein (96 Bit empfohlen)
  → Standard für TLS 1.3, Signal, WireGuard
  → Nonce-Reuse-Angriff: Wenn Nonce zweimal verwendet → vollständige Entschlüsselung!

ChaCha20-Poly1305:
  → Alternative zu AES-GCM
  → Besser auf Systemen ohne AES-Hardware-Beschleunigung (IoT)
  → In TLS 1.3 und Signal Protocol verwendet

SIV (Synthetic IV) - für deterministische Verschlüsselung:
  → Wenn selbe Daten immer selbes Ergebnis brauchen (suchbar)
  → Nonce-Reuse-resistant

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 (BSI TR-02102 Empfehlung 2024):
  RSA-1024: GEBROCHEN (nicht mehr verwenden!)
  RSA-2048: Minimum - akzeptabel bis ~2030
  RSA-3072: Empfohlen bis 2030+
  RSA-4096: Langfristig sicher; für TLS ECDSA vorzuziehen!

Anwendungen:
  → Digitale Signaturen (z.B. Code Signing, PDF-Signatur, PKI Zertifikate)
  → Key Encapsulation (TLS - wird durch ECDH ersetzt)

RSA Padding - kritisch:
  PKCS#1 v1.5: VERALTET, anfällig für Bleichenbacher-Angriff
  OAEP (Optimal Asymmetric Encryption Padding): EMPFOHLEN für Verschlüsselung
  PSS (Probabilistic Signature Scheme): EMPFOHLEN für Signaturen

  # Python - Verschlüsseln 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.

Vergleich:
  RSA-3072 ≈ ECDSA-P256 (256-Bit-Kurve)
  RSA-7680 ≈ ECDSA-P384 (384-Bit-Kurve)
  Viel schneller (Faktor 10-100x), weniger Rechenaufwand → gut für mobile/IoT

Kurven und ihre Eigenschaften:
  P-256 (secp256r1):
    → Standardkurve für TLS, FIDO2, Code Signing, Apple, Google
    → BSI empfohlen: "ausreichend sicher"
  P-384 (secp384r1):
    → Höhere Sicherheit, empfohlen für staatliche Systeme
  Curve25519 (Ed25519 / X25519):
    → Von Daniel Bernstein, keine NIST-Spezifikation
    → Gilt als besonders vertrauenswürdig
    → Standard in: Signal, WireGuard, SSH-Schlüssel
    → Empfehlung für neue Systeme!

Anwendungen:
  ECDSA: Digitale Signaturen (TLS, Bitcoin)
  ECDH:  Key Agreement (Diffie-Hellman auf elliptischen Kurven)
  EdDSA: Moderne Signaturen (Ed25519, Ed448)

SSH-Key Ed25519 generieren:
  ssh-keygen -t ed25519 -C "user@firma.de"
  # Deutlich besser als RSA-2048 default!

# 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:

Eingabe:                         → Hash (SHA-256, 256 Bit)
"Hallo"                          → 185f8db32921bd46d35...
"Hallo!"                         → d9414818c6cde70b1e2... (komplett anders!)
"Das komplette Faust-Epos..."    → 3a2c981d7e4f8b9c...

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”:

NIEMALS: Passwort als MD5 oder SHA-256 speichern!
  → Ohne Salt: Rainbow Tables knacken in Sekunden
  → Mit Salt, aber schnellem Hash: GPU-Cracking

Korrekte Password Hash-Algorithmen:
  bcrypt:   Cost Factor (2^cost Iterations), 72 Byte max, alt aber solide
            Cost Factor 12 (mind.) für neue Anwendungen
  scrypt:   Memory-hard, ressourcenintensiver, NIST SP 800-132 kompatibel
  Argon2id: EMPFOHLEN - OWASP 2024, PHC-Gewinner
            Drei Varianten: Argon2d (GPU-resistant), Argon2i (Timing-safe), Argon2id (beides)
  PBKDF2:   FIPS-140-konform, gut für Compliance-Anforderungen
            Iterations: mind. 600.000 für SHA-256 (OWASP 2023)

OWASP-Empfehlung für Argon2id:
  Memory:  64 MB minimum (m=65536)
  Time:    3 Iterationen minimum (t=3)
  Threads: Anzahl CPU-Kerne (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:

MAC = 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:

Signieren:    Hash(Dokument) + Private-Key-Verschlüsselung = Signatur
Verifizieren: Hash(Dokument) == Public-Key-Entschlüsselung(Signatur) ?

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.

Root CA (selbst-signiert, offline! Im HSM gesperrt)
    │
Intermediate CA (signiert von Root CA)
    │
End-Entity-Zertifikate (signiert von Intermediate CA)
  ├── Webserver-Zertifikat (TLS)
  ├── Code-Signing-Zertifikat
  ├── E-Mail-Zertifikat (S/MIME)
  └── Client-Zertifikat (mTLS)

Warum Root CA offline?
  → Wenn Root CA kompromittiert → alle ausgestellten Zertifikate ungültig
  → Root CA nur für: neue Intermediate CAs ausstellen

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:

SSL 2.0 / 3.0: Komplett veraltet - nie verwenden
TLS 1.0:       Veraltet - POODLE, BEAST Angriffe
TLS 1.1:       Veraltet - seit 2020 abgekündigt
TLS 1.2:       Akzeptabel mit sicheren Cipher Suites
TLS 1.3:       EMPFOHLEN - schneller, sicherer, kein Legacy-Ballast

TLS 1.3 Verbesserungen:
  ✓ Forward Secrecy immer (ECDHE/DHE zwingend)
  ✓ Kein RSA-Key-Transport mehr
  ✓ Schwache Cipher Suites entfernt (RC4, 3DES, MD5, SHA1)
  ✓ Handshake in 1-RTT (statt 2-RTT) - schneller
  ✓ 0-RTT Resumption (aber Replay-Angriff-Risiko beachten!)

TLS 1.3 Cipher Suites (nur noch 5 erlaubt):
  TLS_AES_256_GCM_SHA384         ← Empfohlen
  TLS_CHACHA20_POLY1305_SHA256   ← Empfohlen
  TLS_AES_128_GCM_SHA256         ← Minimum
  TLS_AES_128_CCM_8_SHA256       (IoT)
  TLS_AES_128_CCM_SHA256         (IoT)

Sichere TLS 1.2 Cipher Suites:
  ECDHE-ECDSA-AES256-GCM-SHA384  ← Perfekt
  ECDHE-RSA-AES256-GCM-SHA384    ← Gut
  ECDHE-ECDSA-AES128-GCM-SHA256  ← Gut

  UNSICHER (nicht mehr verwenden):
  ECDHE-RSA-AES256-CBC-SHA       ← CBC anfällig für Padding Oracle
  DH-RSA-AES256-GCM-SHA384       ← Kein "E" = kein Forward Secrecy!
  RC4-SHA                        ← RC4 komplett gebrochen

Nginx Konfiguration (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
  ssllabs.com/ssltest  (Online, 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

Das Quantencomputer-Problem:

Shor's Algorithmus kann RSA und ECC in polynomieller Zeit knacken.
Ein ausreichend leistungsfähiger Quantencomputer würde:
  → RSA-2048 in Stunden/Tagen knacken (statt Milliarden Jahre)
  → ECDSA-P256 ähnlich schnell

"Harvest Now, Decrypt Later":
  → Gegner sammeln heute verschlüsselte Kommunikation
  → Entschlüsseln sie, sobald Quantencomputer verfügbar
  → Zeitrahmen: kryptographisch relevante Quantencomputer ca. 2030-2035
  → Für langfristig sensible Daten: JETZT PQC evaluieren!

NIST PQC Standards (2024 finalisiert):
  ML-KEM (CRYSTALS-Kyber):  Key Encapsulation Mechanism - ersetzt RSA/ECDH in TLS
  ML-DSA (CRYSTALS-Dilithium): Digitale Signaturen - ersetzt RSA/ECDSA
  SLH-DSA (SPHINCS+):        Hash-basierte Signaturen, konservativer Backup

BSI Empfehlung (TR-02102-1):
  → Ab 2025: Hybride Kryptographie (klassisch + PQC)
  → Spätestens 2030: Migration auf PQC abschließen
  → Klassifizierte Daten: SOFORT hybride Kryptographie
  → Crypto-Agility als Designprinzip: Algorithmen austauschbar

TLS 1.3 + PQC (Chrome bereits unterstützt):
  X25519MLKEM768 - Hybride Kurve (X25519 + ML-KEM-768)
  → Bereits in Chrome 131+ und Firefox 132+ aktiv

OpenSSH und Kyber: ab OpenSSH 9.0 hybrid 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

Häufigste Kryptographie-Fehler (OWASP A02:2021):

Fehler 1: Eigene Kryptographie entwickeln
  FALSCH: Eigener AES-Modus implementiert
  RICHTIG: Etablierte Bibliotheken nutzen (OpenSSL, libsodium, cryptography)

Fehler 2: Veraltete Algorithmen
  MD5, SHA-1, DES, 3DES, RC4 → alle gebrochen oder zu schwach
  TLS 1.0, TLS 1.1 → deaktivieren!

Fehler 3: Schlechte Schlüsselverwaltung
  → Hardcoded Keys im Source Code
  → Gleicher Key für Encrypt + Sign
  → Keys nie rotiert
  Lösung: HSM, Vault, AWS KMS, Azure Key Vault

Fehler 4: Falsche Passwort-Hashing
  → MD5/SHA-1 mit oder ohne Salt
  → PBKDF2 mit zu wenig Iterationen
  Lösung: Argon2id mit OWASP-Parametern

Fehler 5: Nonce/IV-Wiederverwendung
  → Nonce in AES-GCM zweimal verwendet → vollständige Entschlüsselung möglich!
  Lösung: os.urandom() für jeden Verschlüsselungsvorgang

Fehler 6: Side-Channel-Angriffe ignorieren
  → Timing-Angriffe bei String-Vergleich
  FALSCH:  if stored_token == provided_token
  RICHTIG: hmac.compare_digest(stored_token, provided_token)

Fehler 7: Zufallszahlen-Fehler
  Python: random.random() → NICHT kryptografisch sicher!
  Java:   Math.random()   → NICHT kryptografisch sicher!
  JS:     Math.random()   → NICHT kryptografisch sicher!
  Korrekt:
  Python:   secrets.token_bytes(32)
  Java:     SecureRandom.getInstanceStrong()
  Node.js:  crypto.randomBytes(32)
  Go:       crypto/rand.Read()

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.