Zusammenfassung

  • Revision 13 zählt authentifizierte Zusatzdaten ausdrücklich zum Klartextvolumen. Wer nur verschlüsselte Nutzdaten misst, erfasst nicht die Größe der Sicherheitsgrenze.
  • Geschützte Nachrichten, fehlgeschlagene Prüfungen, Nonces, Schlüsselzahl und Höchstbelastung eines Schlüssels sind getrennte Belege, die ein prozesslokaler Zähler auseinanderreißen kann.
  • Formeln und Tabellen sind Beispiele, kein allgemeiner Rotationskalender. Die Anwendung bestimmt das Risiko; der Betrieb muss Zählen, Ablehnen, Aktivieren und Stilllegen nachweisen.

Eine Forschungsformel betreibt keinen Zähler

Die Crypto Forum Research Group veröffentlichte am 3. September 2026 Revision 13 von Usage Limits on AEAD Algorithms. Der Text bezeichnet sich nun als Ergebnis des CFRG-Konsenses, bleibt jedoch ein IRTF Internet-Draft. Er kann sich ändern, verfallen oder nie RFC werden.

Wiederholte Nutzung desselben Schlüssels erhöht den Vorteil eines Angreifers. Zur Produktionsregel wird diese Aussage erst mit einem messbaren Geltungsbereich. RFC 5116 definiert Schlüssel, Nonce, Klartext und Zusatzdaten als gemeinsame AEAD-Schnittstelle, führt aber kein Budget für Replikate, Regionen und Neustarts. Es weiß nicht, welche abgewiesenen Eingaben tatsächlich verifiziert wurden.

Der Entwurf liefert die gemeinsame technische Grenze. Risikotoleranz und Ausführungsnachweis bleiben lokale Verantwortung.

Die Anwendung bestimmt „klein genug“

Das Dokument trennt Vorteile gegen authentifizierte Verschlüsselung, Vertraulichkeit und Integrität. Die Anwendung wählt Zielwerte und leitet aus Konstruktion und Einsatzparametern Grenzen ab.

Eine Beispielzeile ist keine fertige Richtlinie. Die Zahlen setzen Nachrichtenlänge, Offline-Arbeit und Zielwahrscheinlichkeit voraus. Bei einem kürzeren Tag können erfolglose Prüfungen früher knapp werden als erfolgreicher Verkehr.

Jeder Grenzwert braucht Kontext: Algorithmus, Tag-Länge, Nachrichtengröße, Angreiferannahme und Schlüsselmenge. Ohne ihn ist ein Verbrauchsprozentsatz nicht prüfbar.

AAD verbraucht ebenfalls Budget

Revision 13 definiert s als Klartext plus authentifizierte Zusatzdaten und lässt L beides umfassen. AAD wird nicht verschlüsselt, fließt aber in die Authentifizierung ein. Header, Sequenzen und Kontextdaten können Arbeit erzeugen, ohne im geheimen Inhalt zu erscheinen.

Wer nur Anwendungsbytes zählt, unterschätzt die Belastung. Bei CCM gehören AAD-, Chiffrat- und Klartextblöcke sowie eine weitere Operation dazu; der Entwurf verwendet konservativ 2L. Sichtbares Volumen ist nicht automatisch die Sicherheitsgröße.

Erfolg und Ablehnung belasten verschiedene Reserven

q zählt geschützte Nachrichten, v erfolglose Entschlüsselungen oder Fälschungsversuche. Schreiber sehen das eine, Leser und Abwehr das andere. Ohne gemeinsames Buch kann ein Dienst Vertraulichkeit steuern und das Integritätsbudget verlieren.

AES-CCM_8 zeigt die Wirkung des 64-Bit-Tags. Das 2^13 in einem Einzelschlüsselbeispiel ist kein universeller Schwellenwert. Entscheidend ist, dass korrekt abgewiesener feindlicher Verkehr knappe Prüfautorität verbraucht.

Der Versuch muss vor dem Verschwinden im Fehlerpfad gezählt werden. Ratenbegrenzung hilft nur dann als Nachweis, wenn sie dieselben Operationen und Schlüssel umfasst.

Flottensumme und heißester Schlüssel

Abschnitt 6 gilt für einen Schlüssel und darf nicht auf Mehrschlüsselumgebungen angewandt werden, auch nicht auf Schlüsselwechsel innerhalb einer Verbindung. In Abschnitt 7 genügt dem Angreifer der Bruch irgendeines Schlüssels.

Rotation senkt die Last je Schlüssel und vergrößert zugleich die Population. Neben aggregierten q und v werden konstruktionsabhängig Höchstwerte pro Schlüssel benötigt: B für verschlüsselte Blöcke, C für ver- und entschlüsselte. Der Durchschnitt verbirgt einen heißen Schlüssel; reine Einzelansichten verbergen den Auswahlvorteil aus vielen Schlüsseln.

Pod-Neustart, Regionswechsel oder Kundenumzug schaffen kein neues Budget, solange das kryptografische Modell gleich bleibt. Der Geltungsbereich folgt Schlüssel und Analyse.

Der Nonce ist ein eigenes Tor

Ein wiederholter Nonce unter demselben GCM-Schlüssel kann Vertraulichkeit und Integrität beschädigen, selbst wenn andere Grenzen nicht erreicht sind. Zuteilung, Nebenläufigkeit, Persistenz nach Ausfall und Rollback brauchen einen eigenen Nachweis.

Revision 13 erläutert zudem, wann s + q + v < 2^64 für GCM bindend wird. Die zuerst erreichte Bedingung muss die Annahme schließen.

Rotation hat vier Zeitpunkte

Erzeugen, Verteilen, für neue Verschlüsselung aktivieren und aus der Annahme entfernen sind getrennte Ereignisse. Leser können den alten Schlüssel noch brauchen, wenn Schreiber bereits gewechselt haben.

Vor der Annahme ist Reserve für verzögerte Messung, Konkurrenz und Wiederholung nötig. Fällt der Zähler aus, muss vorher feststehen, ob geschlossen oder nur ein begrenztes Notbudget verwendet wird. Fehlende Sicht darf nicht still zur Erlaubnis werden.

Was nicht bewiesen ist

Keine TLS- oder QUIC-Implementierung, Cloud, VPN, Datenbank, Geräteflotte oder Schlüsselverwaltung wurde getestet. Handshake, gültiger Tag und Rotationsprotokoll beweisen weder Restbudget noch vollständige Historie noch den Wechsel aller Schreiber.

Die Quellen belegen keinen Vorfall, Angriff, Verbreitungsgrad, Leistungswert oder Konformität. Sie präzisieren die Beweisfrage.

Quellen