Kryptographie ist die unsichtbare Schutzschicht des digitalen Zeitalters — jede HTTPS-Verbindung, jede WhatsApp-Nachricht, jede Bitcoin-Transaktion basiert auf mathematischen Verfahren, die hier erklärt werden.
Symmetrische Kryptographie — AES, Betriebsmodi & typische Fehler
Symmetrische Verschlüsselung verwendet denselben Schlüssel für Ver- und Entschlüsselung. AES (Advanced Encryption Standard) ist der globale Standard seit 2001 (NIST FIPS 197): AES-128, AES-192, AES-256 — die Zahl gibt die Schlüssellänge in Bit an. AES ist eine Blockchiffre (128-Bit-Blöcke), die nicht direkt auf beliebig lange Daten angewendet werden kann — dafür gibt es Betriebsmodi. Die Wahl des Betriebsmodus ist sicherheitskritisch — ein falscher Modus kann AES-256 trotz perfekter Schlüsselverwaltung unsicher machen. ChaCha20-Poly1305 ist die Alternative zu AES-GCM: Schneller auf Hardware ohne AES-NI (z. B. ältere ARM-Prozessoren), verwendet in TLS 1.3, WireGuard, SSH.
- AES-Betriebsmodi — die entscheidende Wahl: ECB (Electronic Codebook) — NIEMALS verwenden! Jeder identische Klartext-Block ergibt denselben Chiffretext-Block → Muster bleiben sichtbar (das berühmte „ECB Penguin“-Bild). CBC (Cipher Block Chaining) — jeder Block wird mit dem vorherigen Chiffretext-Block XOR-verknüpft (IV für den ersten Block). Sicher, aber anfällig für Padding-Oracle-Angriffe (POODLE, Lucky Thirteen): Wenn ein Server bei falschem Padding eine andere Fehlermeldung als bei falschem HMAC zurückgibt, kann der Angreifer den Klartext Byte für Byte entschlüsseln. CTR (Counter) — verwandelt AES in eine Stromchiffre (Zähler wird verschlüsselt, dann XOR mit Klartext). Schnell, parallelisierbar, aber bietet keine Integrität. GCM (Galois/Counter Mode) — der 2026-Standard: CTR + GMAC (Authenticated Encryption with Associated Data, AEAD) — verschlüsselt UND authentifiziert gleichzeitig. Wird in TLS 1.3, IPsec, SSH verwendet. Kritisch: Nonce-Reuse bei GCM ist katastrophal — bei Wiederverwendung einer Nonce kann der Authentifizierungsschlüssel extrahiert und beliebige Nachrichten gefälscht werden.
- Key Derivation Functions (KDF) — von Passwort zu Schlüssel: Ein Benutzerpasswort ist kein kryptographischer Schlüssel — es hat zu wenig Entropie und vorhersagbare Muster. KDFs wandeln Passwörter in sichere Schlüssel um: PBKDF2 (Password-Based Key Derivation Function 2): Iteriert HMAC-SHA256 tausende Male (NIST-empfohlen: mindestens 600.000 Iterationen seit 2023). Nachteil: Effizient auf GPUs angreifbar. bcrypt: Blowfish-basiert, integrierter Salt, memory-hard (langsamer auf GPUs). scrypt: CPU- und memory-hard (RAM-intensive Berechnung macht GPU-Angriffe teuer). Argon2 (id) — der 2026-Standard (Password Hashing Competition Gewinner): Konfigurierbare CPU-Zeit, Speicherverbrauch und Parallelität. Argon2id ist der empfohlene Modus (Kombination aus Side-Channel-Resistenz und GPU-Resistenz). Empfehlung 2026: Argon2id mit t=3, m=65536 (64 MB), p=4.
- Typische Kryptographie-Fehler in der Praxis: 1) Eigene Kryptographie implementieren („Rolling your own crypto“) — niemals eine eigene Verschlüsselungsimplementierung schreiben, immer bewährte Bibliotheken verwenden (OpenSSL, libsodium, Bouncy Castle). 2) ECB-Modus verwenden — erschreckend häufig in Legacy-Anwendungen. 3) Hartcodierte Schlüssel im Quellcode — Schlüssel müssen in HSMs, Azure Key Vault, HashiCorp Vault gespeichert werden. 4) IV/Nonce-Wiederverwendung — insbesondere bei AES-GCM fatal. 5) Fehlende Integritätsprüfung — Verschlüsselung ohne HMAC/AEAD ermöglicht Bit-Flipping-Angriffe. 6) Schwache Zufallszahlen —
Math.random()oderrand()statt kryptographisch sicherer Generatoren (CSPRNG:/dev/urandom,CryptGenRandom,secrets.token_bytes()). 7) Base64 als „Verschlüsselung“ — Encoding ist keine Verschlüsselung! - Hardware Security Modules (HSM) & Key Management: HSMs sind tamper-resistant Hardware-Geräte, die kryptographische Schlüssel erzeugen, speichern und verwenden, ohne dass der Schlüssel das Gerät jemals verlässt. Einsatz: Zertifizierungsstellen (CA Root Key im HSM), Banking (PIN-Generierung), Database Encryption (TDE Master Key). Standards: FIPS 140-3 (Level 1–4, wobei Level 3 = physischer Manipulationsschutz). Cloud-HSMs: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM — FIPS 140-2 Level 3 zertifiziert. Key Management Best Practices: Regelmäßige Schlüsselrotation (jährlich), Separation of Duties (kein einzelner Admin hat Zugriff auf den vollständigen Schlüssel — Shamir Secret Sharing), Key Ceremony (dokumentierter, überwachter Prozess für Root-Key-Generierung), Crypto-Agility (Systeme müssen schnell auf neue Algorithmen umstellen können — essentiell für Post-Quantum-Migration).
Asymmetrische Kryptographie & ECC — Public-Key-Verfahren
Asymmetrische Kryptographie verwendet ein Schlüsselpaar: Public Key (öffentlich verteilt — zum Verschlüsseln/Verifizieren) und Private Key (geheim — zum Entschlüsseln/Signieren). Die Sicherheit basiert auf mathematischen Problemen, die einfach in eine Richtung, aber schwer umzukehren sind: RSA (Faktorisierung großer Zahlen — n = p × q, wobei p und q große Primzahlen sind), ECC (Diskreter Logarithmus auf elliptischen Kurven), DH/ECDH (Diffie-Hellman — Schlüsselaustausch über unsichere Kanäle). In der Praxis werden hybride Systeme verwendet: Asymmetrische Kryptographie für den Schlüsselaustausch (langsam, nur für kleine Datenmengen), symmetrische Kryptographie (AES) für die eigentliche Datenverschlüsselung (schnell). Beispiel TLS 1.3: ECDHE (Schlüsselaustausch) → AES-256-GCM (Datenverschlüsselung).
- RSA — Klassiker mit Ablaufdatum: RSA (Rivest-Shamir-Adleman, 1977) basiert auf der Schwierigkeit der Faktorisierung: n = p × q (zwei große Primzahlen, je ~1024 Bit für RSA-2048). Verschlüsselung: c = m^e mod n. Entschlüsselung: m = c^d mod n (nur mit Private Key d möglich). Schlüssellängen 2026: 1024-Bit RSA ist gebrochen (seit 2010), 2048-Bit RSA gilt bis ~2030 als sicher (NIST/BSI), 3072-Bit RSA für langfristige Sicherheit empfohlen, 4096-Bit RSA für maximale Sicherheit. RSA-Padding-Angriffe: PKCS#1 v1.5 ist anfällig für Bleichenbacher-Angriff (1998, aber 2026 immer noch relevant — ROBOT-Variante 2018): Ein Angreifer kann durch ~1 Million adaptive Anfragen den RSA-verschlüsselten Pre-Master-Secret entschlüsseln. Lösung: OAEP (Optimal Asymmetric Encryption Padding) statt PKCS#1 v1.5.
- Elliptische-Kurven-Kryptographie (ECC): ECC bietet gleiche Sicherheit bei viel kürzeren Schlüsseln als RSA: 256-Bit ECC ≈ 3072-Bit RSA. Beliebte Kurven: NIST P-256 (secp256r1) — am weitesten verbreitet, von NIST standardisiert (Kritik: möglicherweise NSA-Backdoor in der Kurvenparameter-Wahl — ungeklärt). Curve25519 (Daniel Bernstein) — schnell, constant-time-sicher (immun gegen Timing-Angriffe), keine fragwürdigen Parameter, verwendet in Signal, WireGuard, SSH, TLS 1.3. X25519 (ECDH auf Curve25519) + Ed25519 (Signaturen auf Curve25519) = die 2026-Empfehlung für neue Systeme. ECDHE (Ephemeral Diffie-Hellman auf EC): Für jeden TLS-Handshake wird ein neues Schlüsselpaar generiert → Perfect Forward Secrecy (PFS): Selbst wenn der Private Key kompromittiert wird, können vergangene Sessions nicht entschlüsselt werden.
- Digitale Signaturen — Integrität und Authentizität: Digitale Signaturen garantieren: Authentizität (die Nachricht stammt tatsächlich vom Absender), Integrität (die Nachricht wurde nicht verändert), Nichtabstreitbarkeit (der Absender kann nicht leugnen, signiert zu haben). Ablauf: Sender berechnet Hash (SHA-256) der Nachricht → signiert den Hash mit Private Key → Empfänger verifiziert mit Public Key. Algorithmen: RSA-PSS (RSA mit Probabilistic Signature Scheme — sicherer als PKCS#1 v1.5 für Signaturen), ECDSA (Elliptic Curve Digital Signature Algorithm — NIST P-256/P-384), EdDSA/Ed25519 (Signaturen auf Curve25519 — schnell, deterministisch, constant-time). Wichtig: ECDSA erfordert einen einzigartigen Zufallswert k pro Signatur. Bei Wiederverwendung von k kann der Private Key berechnet werden — genau das passierte bei der PlayStation 3 Master Key Extraktion (2010).
- TLS 1.3 — Kryptographie in der Praxis: TLS 1.3 (RFC 8446, 2018) hat die Kryptographie-Suite drastisch vereinfacht: Nur noch 5 Cipher Suites (statt über 300 in TLS 1.2). Erlaubt: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256. Entfernt: RSA Key Exchange (keine PFS), CBC-Modus (Padding-Oracle), RC4, DES, 3DES, MD5, SHA-1, Static DH. Handshake in 1-RTT (statt 2-RTT in TLS 1.2): ClientHello enthält bereits den Key Share (ECDHE-Parameter) → Server antwortet mit seinem Key Share + Finished → verschlüsselte Kommunikation beginnt. 0-RTT Resumption: Bei Wiederverbindung zum selben Server können Daten bereits im ersten Paket verschlüsselt gesendet werden (mit Replay-Risiko — nur für idempotente Requests).
Post-Quantum-Kryptographie — die Zukunft der Verschlüsselung
Quantencomputer bedrohen die gesamte asymmetrische Kryptographie: Shors Algorithmus kann RSA und ECC in polynomieller Zeit brechen — was auf klassischen Computern Milliarden Jahre dauern würde, schafft ein hinreichend großer Quantencomputer in Stunden. Grovers Algorithmus halbiert die effektive Sicherheit symmetrischer Verfahren (AES-256 → 128-Bit-Sicherheit — ausreichend). Die Harvest Now, Decrypt Later (HNDL)-Bedrohung ist real: Geheimdienste speichern heute verschlüsselten Datenverkehr, um ihn später mit Quantencomputern zu entschlüsseln. Deshalb muss die Post-Quantum-Migration jetzt beginnen — nicht erst, wenn Quantencomputer verfügbar sind. NIST hat 2024 die ersten Post-Quantum-Standards veröffentlicht: ML-KEM (Kyber) für Schlüsselaustausch, ML-DSA (Dilithium) für Signaturen.
- NIST Post-Quantum-Standards (2024): ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, basierend auf CRYSTALS-Kyber): Schlüsselaustausch — ersetzt ECDH. Sicherheitslevel: ML-KEM-512 (128-Bit), ML-KEM-768 (192-Bit), ML-KEM-1024 (256-Bit). Public Key: ~800–1568 Bytes (größer als ECC mit 32–64 Bytes, aber handhabbar). Basiert auf dem Module Learning with Errors (MLWE)-Problem — ein Gitterproblem, das auch für Quantencomputer schwer zu lösen ist. ML-DSA (Module-Lattice-based Digital Signature Algorithm, basierend auf CRYSTALS-Dilithium): Signaturen — ersetzt ECDSA/Ed25519. Sicherheitslevel: ML-DSA-44 (128-Bit), ML-DSA-65 (192-Bit), ML-DSA-87 (256-Bit). Signatur: ~2420–4627 Bytes (deutlich größer als Ed25519 mit 64 Bytes). SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, basierend auf SPHINCS+): Backup-Signatur-Standard — basiert ausschließlich auf Hash-Funktionen (kein Gitter-Problem — maximales Vertrauen in die Sicherheitsannahmen).
- Hybrid-Schlüsselaustausch — der Übergangspfad: Da Post-Quantum-Algorithmen noch relativ jung sind (mögliche Kryptoanalyse-Durchbrüche), empfehlen NIST, BSI und Google den hybriden Ansatz: Klassisch + Post-Quantum kombiniert — z. B. X25519 + ML-KEM-768. Beide Key Shares werden berechnet, die resultierenden Shared Secrets kombiniert. Sicherheit: Selbst wenn ML-KEM gebrochen wird, schützt X25519 weiterhin (und umgekehrt). Google Chrome verwendet seit 2024 X25519Kyber768 für TLS 1.3 — Post-Quantum-Schutz für Milliarden von Nutzern. Signal verwendet seit 2023 PQXDH (Post-Quantum Extended Diffie-Hellman) — X25519 + ML-KEM-1024 für den initialen Schlüsselaustausch. WireGuard experimentiert mit Post-Quantum-Erweiterungen (Rosenpass — ML-KEM-768 als zusätzliche Schicht).
- Quantencomputer-Zeitleiste & Bedrohungshorizont: Stand 2026: Die größten Quantencomputer haben ~1.200 physische Qubits (IBM Condor). Für das Brechen von RSA-2048 werden ~4.000 fehlerkorrigierte logische Qubits benötigt — das entspricht ~20 Millionen physischen Qubits mit heutiger Fehlerkorrektur-Technologie. Prognosen: Optimistisch: Kryptographisch relevante Quantencomputer (CRQC) bis 2030–2035. Konservativ: Bis 2040–2050. BSI-Empfehlung (2024): Post-Quantum-Migration sollte bis 2030 abgeschlossen sein (für Daten mit langfristiger Vertraulichkeit — Regierungsgeheimnisse, Gesundheitsdaten, Unternehmensgeheimnisse). NSA CNSA 2.0 Suite (2022): US-Regierungssysteme müssen bis 2033 auf Post-Quantum migriert sein.
- Crypto-Agility — auf den Wechsel vorbereitet sein: Crypto-Agility bedeutet, dass Systeme schnell auf neue kryptographische Algorithmen umstellen können, ohne komplettes Redesign. Prinzipien: Algorithmus-Parameter nicht hardcoden (Algorithmus, Schlüssellänge, Betriebsmodus als Konfiguration, nicht im Code). Cryptographic Inventory: Dokumentation aller verwendeten Algorithmen, Bibliotheken und deren Versionen im gesamten Unternehmen (erstaunlich wenige Organisationen wissen, wo überall RSA/ECC eingesetzt wird). Abstraction Layer: Kryptographische Operationen über APIs abstrahieren (z. B. HashiCorp Vault Transit Engine, AWS KMS — Algorithmus-Wechsel ohne Code-Änderung). Testing: Automatisierte Tests, die nach veralteten Algorithmen suchen (SHA-1, MD5, RSA-1024, DES, RC4 — sollten Build-Fehler verursachen). Migration-Plan: Phasenweise Umstellung — zuerst TLS/VPN, dann Code-Signing, dann gespeicherte Daten.
Sie benötigen Unterstützung?
Kryptographie ist die Grundlage jeder Sicherheitsarchitektur — von TLS-Konfiguration über Key Management bis zur Post-Quantum-Readiness. Wir unterstützen Sie bei der sicheren Implementierung, HSM-Integration, Crypto-Audit und der Migration auf Post-Quantum-Algorithmen.
Security & Firewall ansehen →
