Zusammenfassung

  • RFC 9106 spezifiziert Eingaben, Parameterwahl und Testvektoren für Argon2 1.3; sie zertifiziert nicht die Kapazität eines realen Authentifizierungsdienstes.
  • Belastbare Evidenz trennt das Budget eines Aufrufs von Gleichzeitigkeit, Speicherhochstand, Warteschlange, Überlastverhalten und der Verteilung alter Parameterbestände.

Eine Login-Anfrage erreicht den Verifier. Im gespeicherten Datensatz stehen Argon2id, Version 19, ein eindeutiges Salt, 64 MiB Speicher, drei Durchläufe und vier Lanes. Der Aufruf gelingt. Offen bleibt die Frage, die den Dienst beherrscht: Was geschieht, wenn Hunderte solcher Aufrufe gleichzeitig um Speicher und Rechenzeit konkurrieren?

RFC 9106 legt diese Grenze selbst frei. Ihr Auswahlverfahren fragt zuerst, wie viel Speicher ein Aufruf beanspruchen darf und wie viel Zeit ein Aufruf kosten darf. Danach wird die Zahl der Durchläufe angepasst; dauert schon ein Durchlauf zu lange, soll der Speicher sinken. Sicherheit wird nicht über einen Namen bezogen. Sie wird innerhalb eines Ressourcenrahmens gewählt.

Dieser Rahmen geht unmittelbar in die Berechnung ein. Passwort P, Salt S, Parallelität p, Tag-Länge, Speicher m, Durchläufe t, Version und Typ speisen den Initial-Hash, ebenso optionale Secret- und Associated-Data-Werte. Der Speicher besteht aus 1-KiB-Blöcken und wird auf p Lanes verteilt. Lanes können innerhalb einer Slice parallel voranschreiten, synchronisieren aber an deren Grenzen. Weitere Durchläufe besuchen die Matrix erneut. „Wir verwenden Argon2id“ lässt daher die maßgeblichen Kostenwerte offen.

Die Spezifikation empfiehlt ein je Passwort einzigartiges Salt von 16 Byte. Es verhindert, dass gleiche Passwörter in dasselbe wiederverwendbare Ziel fallen. Es ist jedoch weder geheim noch der Arbeitspreis eines Versuchs. Der Verifier muss Version und Parametertupel je Datensatz bewahren, damit alte Einträge geprüft und später aufgewertet werden können.

Zwei Empfehlungen machen den Tausch sichtbar. Die erste nutzt 2 GiB, einen Durchlauf und vier Lanes. Die speicherbeschränkte Alternative nutzt 64 MiB, drei Durchläufe und vier Lanes. Das Dokument enthält außerdem Beispiele für einen 2-GHz-Prozessor, darunter eine Backend-Authentifizierung mit vier Kernen, acht Lanes, 4 GiB und 0,5 Sekunden. Das sind Bezugspunkte unter benannten Annahmen, keine Zusagen für Container, virtuelle Maschinen, NUMA, Allocator-Verhalten, Speicherbandbreite oder Produktions-Tail-Latenz.

Testvektoren leisten noch weniger. Sie vergleichen Zwischenblöcke und den finalen Tag bei festen Eingaben, etwa 32 KiB, drei Durchläufen und vier Lanes. Ein bestandener Test belegt kompatible Arithmetik für diesen Fall. Er misst weder Resident-Set-Spitzen noch Abbruch, Speicherbereinigung, Scheduler-Einfluss, Warteschlangenwachstum oder die Reaktion auf eine gescheiterte Allokation.

In dieser Lücke kann ein stark wirkender Hash zur schwachen Betriebspolitik werden. 64 MiB mal gleichzeitige Aufrufe ist eine Planungsgrenze, kein Messwert. Bibliotheks-Overhead, Wiederverwendung im Allocator und Speicherbandbreite verschieben das Ergebnis. Der Dienst muss festlegen, was am Rand geschieht: einreihen, ablehnen, drosseln, abbrechen, andere Arbeit abwerfen oder geschlossen scheitern. Ein stiller Rückfall auf billigere Parameter ändert die Sicherheitsbehauptung; Prozesserschöpfung macht die Abwehrkosten zur Verfügbarkeitswaffe.

Migration erzeugt eine zweite Illusion. Die aktuelle NIST-Leitlinie verlangt, Verfahren und Kostenfaktor mit jedem Passwort zu speichern, damit sie angehoben werden können. Möglich ist nicht erledigt. Ein neuer Standardwert kann nur neue Passwörter und Konten erfassen, die sich seit der Änderung angemeldet haben. Die tatsächliche Kontrollfläche ist die Verteilung gespeicherter Tupel, der Rehash-Auslöser, fehlgeschlagene Upgrades und der Restbestand unter dem alten Budget.

Auch die Aussage über Angriffe braucht Grenzen. Memory Hardness erhöht den Ressourcenaufwand je Versuch und zwingt Angreifer zu Zeit-Speicher-Kompromissen. Sie verrät weder Passwortqualität noch Umfang eines Abflusses, gegnerische Hardware, Energiepreis oder Kontowert. RFC 9106 bezeichnet sich als Informational-Ergebnis der IRTF, nicht als Internet-Standards-Track-Spezifikation, und warnt vor ungeeigneter unmittelbarer Nutzung. Ihre Autorität liegt in der präzisen Funktion, nicht in einem Zertifikat für unbeobachtete Systeme.

Damit ist auch die Grenze zur RFC-9807-Berichterstattung gezogen. OPAQUE platziert eine KSF beim Client und wirft Fragen zu Passwortunsichtbarkeit, OPRF-Seed-Verwahrung und Record-Migration auf. Hier geht es um den gewöhnlichen serverseitigen Verifier und darum, wie Salt, Speicher, Durchläufe und Lanes als viele gleichzeitige Aufrufe bezahlt werden. Das eine ist eine Protokoll- und Verwahrungskarte, das andere ein Kapazitäts- und Evidenzbuch.

Ein Betriebsbeleg sollte Typ und Version, Salt-Regel, m, t, p, Tag-Länge und optionale Secret-Regel festhalten; Bibliothek und Hardwareklasse; kalte und warme Latenzperzentile; Speicherhochstände je Aufruf und Prozess; aktive Aufrufe; Queue-Tiefe; Ablehnung und Timeout; Abbruch und Bereinigung; CPU- und Bandbreitendruck; Parameterpopulation; Rehash-Erfolg und -Fehler; Drosselung, Erholung und Fehlermodus. Ein erfolgreicher Hash steht am Anfang dieser Kette.

Quellen

Spezifikation und Status: RFC 9106, RFC-Editor-Eintrag, IETF-Datatracker und das Argon2-Paper. Entstehung: Password Hashing Competition. Verifier-Anforderungen: NIST-Leitlinie zu Authentikatoren und NIST-Passwortanalyse. Benachbarte Grenze: RFC 9807. Analytischer Rahmen: Minimum Initial Specification, Reality Layers und Running-Code Primacy.