Kryptografie-Grundlagen
Drei Werkzeuge tragen fast die ganze IT-Sicherheit: symmetrische Verschlüsselung, Schlüsselpaare und Hashfunktionen. Was jedes kann, was nicht – und was Quantencomputer daran ändern.
Fast alles in der IT-Sicherheit baut auf drei Werkzeugen auf: symmetrische Verschlüsselung (ein gemeinsamer Schlüssel, schnell – AES), asymmetrische Verfahren (ein Schlüsselpaar aus öffentlichem und privatem Schlüssel – RSA, elliptische Kurven) und Hashfunktionen (ein unumkehrbarer Fingerabdruck beliebiger Daten – SHA-256).
Aus ihnen werden alle höheren Bausteine zusammengesetzt: digitale Signaturen, Zertifikate, Passwortspeicherung, TLS. Die wichtigste Regel für Entwickler: Nie selbst erfinden, nie selbst implementieren – fertige, geprüfte Bibliotheken richtig benutzen. Die meisten Fehler passieren nicht in der Mathematik, sondern beim Benutzen.
Die drei Werkzeuge
Symmetrisch
Ein Schlüssel zum Ver- und Entschlüsseln, wie ein Tresor mit einem Code. Extrem schnell, auch für Gigabytes. Problem: Wie bekommt die andere Seite den Schlüssel?
Asymmetrisch
Ein Schlüsselpaar. Den öffentlichen kann jeder haben, den privaten nur der Besitzer. Löst das Verteilungsproblem, ist aber tausendfach langsamer.
Hash
Kein Schlüssel. Macht aus beliebigen Daten einen Fingerabdruck fester Länge – unumkehrbar. Prüft, ob sich etwas verändert hat.
In der Praxis werden sie immer kombiniert. TLS benutzt alle drei: einen asymmetrischen Schlüsselaustausch, um einen gemeinsamen Schlüssel zu vereinbaren, Signaturen und Hashes für die Zertifikate, und symmetrische Verschlüsselung für die eigentlichen Daten.
Hashfunktionen: der Fingerabdruck
Eine kryptografische Hashfunktion wie SHA-256 macht aus beliebigen Daten – einem Wort oder einer Datei mit Gigabytes – genau 256 Bit. Drei Eigenschaften machen sie nützlich:
- Einwegfunktion: Aus dem Hash lässt sich die Eingabe nicht berechnen.
- Kollisionsresistenz: Es ist praktisch unmöglich, zwei verschiedene Eingaben mit gleichem Hash zu finden.
- Lawineneffekt: Ändert sich ein einziges Bit der Eingabe, ändert sich etwa die Hälfte der Ausgabe – völlig unvorhersehbar.
Hashes stecken überall: Git benennt jeden Commit nach seinem Hash. Downloads geben eine Prüfsumme an. Signaturen unterschreiben nicht die ganze Datei, sondern ihren Hash. Und Passwörter werden – mit speziellen, absichtlich langsamen Hashfunktionen – gehasht gespeichert; mehr dazu im nächsten Eintrag.
Ältere Verfahren gelten als gebrochen: Für MD5 lassen sich Kollisionen in Sekunden erzeugen, für SHA-1 wurde 2017 die erste praktische Kollision veröffentlicht. Als Prüfsumme gegen zufällige Fehler taugen sie noch, für Sicherheit nicht mehr.
HMAC: Hash mit Schlüssel
Ein Hash allein beweist nur, dass Daten unverändert sind – solange der Hash selbst sicher übermittelt wurde. Wer die Daten fälscht, kann auch einen neuen Hash berechnen. Ein HMAC mischt einen geheimen Schlüssel in den Hash: Nur wer den Schlüssel kennt, kann den richtigen Wert erzeugen oder prüfen. So sichern etwa Webhooks und viele Token ihre Echtheit.
Symmetrisch: AES
Der Standard für symmetrische Verschlüsselung ist AES, seit 2001 vom US-Standardinstitut NIST festgelegt, mit Schlüsseln von 128 oder 256 Bit. Moderne Prozessoren haben eigene Befehle dafür und verschlüsseln Gigabytes pro Sekunde. Eine Alternative ist ChaCha20, schnell auch ohne Hardware-Unterstützung.
AES verschlüsselt immer genau 16 Byte auf einmal. Für längere Daten braucht man einen Betriebsmodus – und hier passieren die klassischen Fehler. Der naive Modus ECB verschlüsselt jeden Block einzeln mit demselben Schlüssel. Gleiche Blöcke ergeben dann gleiche Geheimtexte:
Richtig ist heute ein AEAD-Modus („authenticated encryption“): AES-GCM oder ChaCha20-Poly1305. Sie verschlüsseln nicht nur, sondern hängen auch eine Prüfsumme an – eine Veränderung am Geheimtext fällt beim Entschlüsseln sofort auf. Ihre eine harte Regel: Jede Verschlüsselung braucht einen neuen Startwert (Nonce, IV). Wer mit demselben Schlüssel zweimal dieselbe Nonce benutzt, verrät Teile der Klartexte und ermöglicht Fälschungen.
Asymmetrisch: Schlüsselpaare
Ein Bild dafür ist ein Briefkasten: Einwerfen kann jeder (öffentlicher Schlüssel), öffnen nur, wer den Schlüssel hat (privater Schlüssel). Umgekehrt funktioniert die Signatur: Nur der Besitzer des privaten Schlüssels kann sie erzeugen, aber jeder mit dem öffentlichen Schlüssel kann sie prüfen – wie ein Siegel.
Das älteste und bekannteste Verfahren ist RSA von 1977. Seine Sicherheit beruht darauf, dass man zwei große Primzahlen leicht multiplizieren, das Produkt aber praktisch nicht wieder zerlegen kann. Hier eine Spielzeug-Version mit winzigen Primzahlen:
Mit 3233 kommt jeder in Sekundenbruchteilen auf 61 × 53. Echte RSA-Schlüssel haben 2048 bis 4096 Bit – Zahlen mit über 600 Dezimalstellen, die mit heutigen Computern nicht zerlegbar sind. Echtes RSA benutzt außerdem eine zufällige Auffüllung (Padding); die nackte Formel aus dem Spielzeug wäre unsicher.
Moderne Systeme setzen meist auf elliptische Kurven: gleiche Sicherheit mit viel kürzeren Schlüsseln und schnelleren Rechnungen. Ein 256-Bit-Kurvenschlüssel entspricht etwa einem 3072-Bit-RSA-Schlüssel. Bekannte Verfahren: X25519 für den Schlüsselaustausch, Ed25519 und ECDSA für Signaturen.
Zufall
Jeder Schlüssel, jede Nonce, jedes Sitzungs-Token ist nur so gut wie der Zufall, aus dem es entstand. Gewöhnliche Zufallsgeneratoren wie java.util.Random sind für Simulationen gebaut: Aus wenigen Ausgaben lässt sich der innere Zustand berechnen und jede künftige Zahl vorhersagen. Für alles Sicherheitsrelevante gibt es kryptografisch sichere Generatoren – in Java SecureRandom, der aus dem Zufall des Betriebssystems schöpft.
Quantencomputer
Ein ausreichend großer Quantencomputer könnte mit dem Shor-Algorithmus große Zahlen zerlegen und das Problem hinter elliptischen Kurven lösen. Damit wären RSA, ECDH und ECDSA gebrochen – also fast alle heutigen asymmetrischen Verfahren. Symmetrische Verfahren und Hashes trifft es viel schwächer: AES mit 256 Bit gilt weiter als sicher.
So einen Quantencomputer gibt es noch nicht. Trotzdem eilt es, wegen „harvest now, decrypt later“: Wer heute verschlüsselten Verkehr aufzeichnet, kann ihn später entschlüsseln. Deshalb hat NIST im August 2024 die ersten Post-Quanten-Standards veröffentlicht: ML-KEM (früher Kyber) für den Schlüsselaustausch, ML-DSA (früher Dilithium) und SLH-DSA für Signaturen. Browser und große Anbieter nutzen ML-KEM bereits – meist als Hybrid zusammen mit X25519, damit die Verbindung sicher bleibt, falls sich eines der beiden Verfahren als schwach herausstellt. Java bringt ML-KEM und ML-DSA seit Version 24 mit.
Für Entwickler übersetzt
// Symmetrisch: AES-GCM – verschlüsselt und schützt vor Veränderung
KeyGenerator kg = KeyGenerator.getInstance("AES");
kg.init(256);
SecretKey key = kg.generateKey();
byte[] iv = new byte[12];
new SecureRandom().nextBytes(iv); // für JEDE Verschlüsselung neu!
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(128, iv));
byte[] geheim = c.doFinal("Hallo".getBytes(UTF_8)); // IV mitspeichern – er ist nicht geheim
// Hash
byte[] h = MessageDigest.getInstance("SHA-256").digest("Hallo".getBytes(UTF_8));
System.out.println(HexFormat.of().formatHex(h));
// Signatur mit Ed25519 (seit Java 15)
KeyPair kp = KeyPairGenerator.getInstance("Ed25519").generateKeyPair();
Signature s = Signature.getInstance("Ed25519");
s.initSign(kp.getPrivate()); s.update(daten); byte[] sig = s.sign();
s.initVerify(kp.getPublic()); s.update(daten); boolean echt = s.verify(sig);| Regel | Warum |
|---|---|
Kein "AES" ohne Modus | Cipher.getInstance("AES") bedeutet in Java AES/ECB/PKCS5Padding – genau der Modus aus dem Bild oben. |
SecureRandom, nie Random | für Schlüssel, IVs, Token, Passwort-Reset-Links. |
| Signaturen und MACs zeitkonstant vergleichen | MessageDigest.isEqual(a, b) statt Arrays.equals – sonst verrät die Laufzeit, wie viele Bytes stimmen. |
| Schlüssel gehören nicht in den Code | nicht ins Repository, nicht in die application.properties. Dafür gibt es Schlüsselverwaltungen: Vault, Cloud-KMS, Kubernetes Secrets. |
| Lieber eine Bibliothek höherer Ebene | Die JCA bietet Bausteine, keine fertigen Rezepte. Bibliotheken wie Google Tink nehmen viele Entscheidungen sicher vorweg. |