Argon2 · Encrypt-then-MAC · Speicherschutz
🛡️Sicherheitsmodell
Eine KDBX-Datei darf in falsche Hände geraten – solange das Passwort gut ist. Drei Bausteine sorgen dafür: eine teure Schlüsselableitung gegen Raten, Authentisierung gegen Manipulation und der Schutz der Werte im Arbeitsspeicher.
🧠Warum Argon2?
Das Problem
Wer die Datei hat, kann offline beliebig viele Passwörter ausprobieren. Ohne KDF kostet jeder Versuch nur zwei SHA-256 und einen HMAC – Grafikkarten schaffen davon Milliarden pro Sekunde. Die KDF macht jeden einzelnen Versuch absichtlich teuer.AES-KDF (KDBX 3.1)
Viele AES-Runden hintereinander: kostet Zeit, aber praktisch keinen Speicher. Angreifer mit GPUs oder Spezialchips (ASICs) können tausende Versuche parallel rechnen – die Bremse wirkt beim Angreifer viel schwächer als beim Nutzer.Argon2 (KDBX 4)
Speicherhart (RFC 9106): Jeder Versuch braucht m Byte RAM, der t-mal durchlaufen wird. Speicher ist auf GPUs knapp und teuer – die Parallelität des Angreifers wird durch seinen Speicher begrenzt. KeePass empfiehlt auf Client-Geräten Argon2d; Argon2id ist der allgemeine Kompromiss laut RFC.💸Brute-Force-Kosten – gemessen und grob hochgerechnet
⏱️ 1. Messen – in diesem Browser
Argon2 (64 MiB, t=2, p=2)
–
pro Rateversuch (hash-wasm, 1 Thread)
AES-KDF
–
Runden pro Sekunde (WebCrypto) – Speicherbedarf ≈ 0
🧮 2. Hochrechnen – grob!
Erwartete Zeit = ½ · Suchraum · Zeit pro Versuch ÷ Beschleunigung. Die Beschleunigung steht für „der Angreifer hat so viel mehr Rechenleistung als dieser Browser“ – eine Annahme, keine Messung.
Speicherhärte: Bei 64 MiB pro Versuch passen höchstens 384 Argon2-Berechnungen gleichzeitig in 24 GiB – egal wie viele Rechenkerne die Karte hat. AES-KDF braucht nur wenige Byte pro Versuch und kann jeden Kern auslasten.
| Passwort | Suchraum | Bits | mit Argon2 (gemessen) | ohne KDF (1 µs/Versuch angenommen) |
|---|---|---|---|---|
| 6 Kleinbuchstaben | 26⁶ | 28.2 | erst messen | 154 ms |
| 8 Zeichen a–z, A–Z, 0–9 | 62⁸ | 47.6 | erst messen | 30.3 h |
| 12 Zeichen, 94 druckbare ASCII | 94¹² | 78.7 | erst messen | ≈ 10^6.9 Jahre |
| 4 Diceware-Wörter | 7776⁴ | 51.7 | erst messen | 21.2 Tage |
| 6 Diceware-Wörter | 7776⁶ | 77.5 | erst messen | ≈ 10^6.5 Jahre |
Die Spalte „ohne KDF“ nimmt willkürlich 1 µs pro Versuch im Browser an, um den Unterschied zu zeigen. Reale Angriffe hängen von Hardware, Implementierung und davon ab, ob das Passwort wirklich zufällig gewählt wurde – menschliche Passwörter haben meist viel weniger Bits als die Tabelle annimmt.
Die wichtigste Stellschraube bleibt das Passwort
Jedes zusätzliche Bit verdoppelt den Aufwand. Die KDF verschiebt die Kurve um einen konstanten Faktor (Millisekunden statt Mikrosekunden), eine Passphrase aus 6 Zufallswörtern verschiebt sie um viele Größenordnungen. KeePass bietet dafür den Knopf „1 Second Delay“, der die Parameter so einstellt, dass das Öffnen auf dem eigenen Gerät etwa eine Sekunde dauert.
🧷Integrität: Encrypt-then-MAC
- Header-HMAC: Der offen lesbare Header (inkl. KDF-Parameter!) ist mit HMAC-SHA-256 authentisiert. Ein Angreifer kann also nicht unbemerkt die Argon2-Parameter senken oder die Chiffre tauschen.
- Block-HMACs: Jeder Chiffretext-Block wird geprüft, bevor er entschlüsselt wird. Der Schlüssel hängt vom Blockindex ab – Vertauschen, Weglassen oder Anhängen fällt auf; der leere Endblock verhindert unbemerktes Abschneiden.
- Frühe Passwort-Erkennung: Ein falsches Passwort zeigt sich am Header-HMAC, ohne Daten zu entschlüsseln (siehe Debugger).
KDBX 3.1 im Vergleich: kein HMAC. Der Header wird erst nach dem Entschlüsseln über Meta/HeaderHash im XML bestätigt, das Passwort über 32 StreamStartBytes. Die Hash-Blöcke im Klartext enthalten ungeschlüsselte SHA-256-Werte – sie erkennen Beschädigung, sind aber keine Authentisierung des Chiffretexts.