Zusammenfassung

  • RFC 10032 ist eine Informational-Veröffentlichung des IRTF-Streams auf Grundlage des CFRG-Konsenses, keine Vorgabe des IETF Standards Track. Die sechs IANA-Kennungen schaffen stabile Namen, keine Einführungspflicht.
  • Das Register unterscheidet AEGIS-128L, AEGIS-256 und vier parallele X2/X4-Formen, codiert aber nicht die Wahl eines 128- oder 256-Bit-Tags. Parallele Modi sind optional und verlangen Einigkeit über die genaue Variante.
  • Ein Bibliotheksselbsttest bestätigt eine Primitive für feste Testdaten. Er belegt weder die Auswahl zweier Gegenstellen noch das geladene Binary, den CPU-Pfad, die Nonce- und AD-Konstruktion oder den Schutz realer Sitzungen.
  • Ein Verwahrungsbeleg sollte Dokument und Register, Protokollprofil, authentisierte Auswahl, Codepunkt und Tag, Schlüssel- und Nonce-Lebenszyklen, AD-Codierung, Laufzeitpfad, Positiv- und Negativtests, Fehlerverhalten, Zähler, Fallback und Rollback verbinden.

Eine Kennung koordiniert Namen

IANA weist AEAD_AEGIS128L den Wert 32 und AEAD_AEGIS256 den Wert 33 zu. 34 und 35 stehen für AEGIS-128X2/X4, 36 und 37 für AEGIS-256X2/X4. Damit können Spezifikationen dieselbe Variante benennen, ohne inkompatible Verfahren unter einer öffentlichen Zahl zu vermischen.

Die Zahl ist jedoch kein Sitzungsprotokoll. RFC 5116, Grundlage der AEAD-Schnittstelle und des Registers, sagt ausdrücklich, dass eine Registrierung weder das Verfahren noch seine Sicherheit empfiehlt. Auch Wiederholungsschutz und Zugriffspolitik liegen außerhalb der Schnittstelle. Sie gehören zum aufrufenden Protokoll und dessen Betrieb.

RFC 10032 liefert Definitionen, Parameter, Betriebshinweise und Testvektoren. Er definiert keine allgemeine Aushandlung für TLS, IPsec, QUIC, Speicher oder anwendungsspezifische Kanäle. Das jeweilige Profil muss festlegen, ob AEGIS angeboten wird, wie eine Kennung abgebildet wird, welche Tag-Länge gilt, wie Schlüssel und Nonces entstehen, welche Bytes Associated Data bilden und was bei Authentisierungsfehlern geschieht.

„Die Bibliothek unterstützt AEGIS“ ist somit eine Fähigkeitsaussage. „Diese Sitzung nutzte AEGIS-128X4 mit diesen Parametern“ ist eine Auswahl- und Laufzeitaussage. Dazwischen liegt der Beleg.

Der Publikationsstream gehört zur Einordnung

RFC 10032 erschien im September 2026 im IRTF-Stream als Informational. Er gibt den Konsens der CFRG wieder, weist aber selbst darauf hin, dass er kein IETF-Produkt oder -Standard ist und Forschungsergebnisse möglicherweise nicht für eine Einführung geeignet sind.

Das ist keine technische Abwertung, sondern beschreibt Prüfung und Autorität. RFC 5743 erläutert Vorbereitung in der Forschungsgruppe, IRSG-Prüfung und Konfliktprüfung durch die IESG. RFC 7841 grenzt Nicht-IETF-Streams von der breiten Prüfung und Annahme eines IETF-Standards ab.

Vier Tatsachen bleiben getrennt: Forschungskonsens der CFRG, Publikationsfreigabe der IRSG, Konfliktprüfung der IESG und eindeutige IANA-Zuteilung. Keine davon beweist die Übernahme durch ein Protokoll, eine Produktvoreinstellung oder die Auswahl durch zwei Endpunkte.

Am 20. September zeigte die öffentliche IANA-Seite alle sechs Einträge, während die Referenz noch draft-18 nannte und als Aktualisierungsdatum den 7. Juli auswies. Diese beobachtete Verzögerung macht die Kennungen nicht ungültig. Sie zeigt, warum eine Prüfung Publikations- und Registerstand jeweils datiert festhalten muss.

Der Codepunkt lässt die Tag-Länge offen

AEGIS-128L arbeitet mit 128-Bit-Schlüssel und -Nonce, AEGIS-256 mit jeweils 256 Bit. Beide erlauben Authentisierungs-Tags von 128 oder 256 Bit. Die sechs Registernamen codieren Familie und gegebenenfalls Parallelitätsgrad, nicht aber die Tag-Länge.

Diese Wahl verändert Sicherheitszusage und Drahtformat. RFC 10032 nennt im beschriebenen Commitment-Szenario ungefähr 2^64 Aufwand beim 128-Bit-Tag und 2^128 beim 256-Bit-Tag. Zwei Endpunkte können Codepunkt 32 vereinbaren und dennoch unterschiedliche Tag-Grenzen erwarten.

Ebenso muss feststehen, ob Ciphertext und Tag getrennt bleiben oder ob der Tag unmittelbar folgt. „AEGIS-128L“ allein verrät nicht, wie viele Bits der Empfänger gelesen und wo er getrennt hat.

Associated Data sind Teil des Profils. RFC 5116 nennt Klartextfelder wie Adressen, Ports, Sequenz- und Versionsnummern. RFC 10032 schränkt eine Full-Commitment-Eigenschaft auf den Fall ein, in dem der Angreifer die AD nicht kontrolliert, und beschreibt Konstruktionen für stärkere Anforderungen. Felder, Reihenfolge, Längen, Version und Domänentrennung sind deshalb Protokollbeweise.

Parallelität ist zugleich Kompatibilität

AEGIS-128X und AEGIS-256X nutzen breite Vektorregister und Vektor-AES-Befehle; X2 und X4 bezeichnen die Parallelitätsgrade zwei und vier. Der Gewinn hängt von Architektur und Implementierung ab.

RFC 10032 setzt eine Grenze: Ein Protokoll sollte eine parallele Form nur wählen, wenn alle Beteiligten derselben konkreten Variante zustimmen. AEGIS-128L und AEGIS-256 sollen die Vorgaben bleiben; Implementierungen dürfen parallele Formen weglassen.

Ein schneller X4-Benchmark schafft daher keine portable Suite. Die Gegenstelle kann nur die Basisform besitzen, das Binary ohne X-Pfad gebaut sein, eine VM nach der Migration andere CPU-Merkmale sehen oder der Dispatcher unbemerkt zurückfallen, obwohl die Konfiguration weiterhin „AEGIS“ meldet.

Ein belastbarer Nachweis trennt Angebot und Auswahl des Protokolls, die genaue Fähigkeit jeder Gegenstelle und den tatsächlich ausgeführten Pfad. Diese Ebenen hängen zusammen, ersetzen einander aber nicht.

Nonce-Verwahrung bleibt trotz großer Zahlen

Für Verschlüsselung verlangt RFC 10032 einen einmaligen Nonce je Schlüssel, auch über unterschiedliche Tag-Längen hinweg. Wiederverwendung legt sofort die bitweise Differenz zweier Nachrichten offen. Nonces dürfen öffentlich oder vorhersehbar sein und aus Zählern oder langperiodischen Generatoren stammen.

Zufällige Nonces der 128-Bit-Familie dürfen bei der genannten Kollisionswahrscheinlichkeit von etwa 2^-33 bis zu 2^48 Nachrichten je Schlüssel abdecken. Für die 256-Bit-Familie nennt der RFC keine praktische Zufallsgrenze. Das hebt weder die Eindeutigkeitsregel noch die betriebliche Rechenschaft auf.

Die Einführung muss Eindeutigkeitsdomäne, Schlüsselepoche, Neustartpersistenz, Zufallsquelle, Shard-Zuteilung und Erkennung von Snapshot-Rollback oder Klonen festlegen. Zwei aus demselben Snapshot gestartete Prozesse können denselben nächsten Wert beanspruchen. Die Feldbreite bestimmt keinen Eigentümer.

Auch der Schlüssel braucht Herkunft oder Ableitung, Protokollkontext, Epoche, Nutzertrennung, Kennung und Löschgrenze. Dass ein flüchtiger Schlüssel nach der Initialisierung gelöscht werden kann, beweist noch nicht das Verhalten des ausgewählten Builds.

Selbsttests enden vor der Live-Verbindung

RFC 10032 enthält umfangreiche Vektoren für AESRound, Basisalgorithmen, X2/X4 und MAC-Formen. Sie decken Byte-Reihenfolge, Abschluss, Teilblöcke und Tag-Bildung ab. Vergleiche unabhängiger Implementierungen erhöhen den Wert.

Negativtests müssen einen geänderten Tag, ein AD-Feld, den Nonce und den Parallelitätsgrad ablehnen. Bei einem Fehler dürfen ungeprüfter Klartext und berechnete Tags nicht ausgegeben werden; der entschlüsselte Puffer ist zu überschreiben und der Tag zeitkonstant zu vergleichen. Ein beschleunigter Pfad, der Positivvektoren besteht, aber vor der Prüfung Daten freigibt, ist nicht gleichwertig.

Auch ein perfekter Testlauf beweist nicht, dass ein echter Handshake die Suite angeboten, beide Seiten die Auswahl authentisiert, der erwartete Build geladen, der Hardwarepfad genutzt oder der Zähler innerhalb der Epoche geblieben ist. Dafür braucht es Laufzeitbelege.

Ein Beleg aus vierzehn Teilen

Der folgende Verwahrungsbeleg ist Daniel Kades redaktioneller Betriebsvorschlag, kein Feld aus RFC 10032 und kein Zertifikat von IETF, IRTF, CFRG oder IANA.

Erstens: Dokumentidentität, Stream, Kategorie, Publikations- und Errata-Stand sowie Register-Snapshot. Zweitens: aufrufendes Protokoll, Version, Profil und Konfigurationsgeneration. Drittens: authentisiertes Angebot und Auswahl oder ein gleichwertiger Einigungsnachweis.

Viertens: Nummer und exakte Basis-, X2- oder X4-Variante. Fünftens: Tag-Länge und Framing. Sechstens: Peer-Fähigkeit und Verhalten ohne Unterstützung. Siebtens: Schlüsselquelle, Ableitung, Kontext, Epoche, Kennung und Löschung.

Achtens: Nonce-Konstruktion, Persistenz, Eindeutigkeitsdomäne, Neustart und Zähler. Neuntens: AD-Felder und kanonische Codierung. Zehntens: Bibliotheks-Build, CPU-/Vektorpfad und Fallback. Elftens: Positivvektoren, Implementierungsvergleich und Negativfälle.

Zwölftens: Fehlerssemantik, Klartextunterdrückung, zeitkonstanter Vergleich und Alarmierung. Dreizehntens: begrenzte Live-Sitzungs- oder Paketbelege und Nutzungsmetrik. Vierzehntens: Ersatzregeln, Downgrade-Abwehr, Rollback-Auslöser, Ausstieg aus dem Kompatibilitätssatz und Aufbewahrungsfrist.

Das Register beweist keinen Handshake; der Handshake keine Nonce-Persistenz; der Vektor nicht das geladene Binary; ein Paket ohne Epoche und AD-Regeln nicht seine Annahme. Der Beleg verhindert, dass all diese Aussagen im Wort „unterstützt“ verschwinden.

Quellen