Zusammenfassung

  • RFC 10032 definiert AEGIS für authentifizierte Verschlüsselung, als Stromgenerator und als Nachrichtenauthentifizierungscode. Verschlüsselung verlangt ein einmaliges (Schlüssel, Nonce)-Paar und hält Klartext bis zur Prüfung zurück; der Strommodus verwirft den Tag; nur der MAC erlaubt Paarwiederverwendung für verschiedene Eingaben.
  • IANA-Codepunkt, Testvektor und Leistungswert belegen nicht, welche Rolle eine Anwendung aufgerufen hat. Dafür braucht es Nachweise über Schlüsselzweck, Nonce-Raum, Associated Data, Laufzeitpfad und die Grenze, die ungeprüfte Ausgabe zurückhielt.

RFC 10032 erschien im September 2026 als Informational RFC im IRTF-Stream und dokumentiert CFRG-Konsens. Es ist kein IETF-Standards-Track-Dokument. Beschrieben werden AEGIS-128L, AEGIS-256 sowie die für breite Vektorregister spezialisierten Varianten AEGIS-128X und AEGIS-256X. Alle bauen auf der AES-Verschlüsselungsrunde auf.

Die IANA vergab die AEAD-Nummern 32 bis 37 für Basis-, X2- und X4-Formen. Ein solcher Eintrag koordiniert Namen. Er enthält weder die API-Rolle noch die Taglänge, Datenstruktur, Schlüsselaufgabe, Nonce-Zuteilung oder Fehlerbehandlung.

Der bestehende BTW-Beitrag zu RFC 10032 besitzt die Grenze zwischen Codepunkt, Aushandlung und tatsächlicher Sitzung. Diese Analyse setzt später an: Wenn die Familie schon gewählt ist, welche der drei Funktionen lief, und welche Aussage darf ihre Ausgabe tragen?

AEAD sperrt Klartext bis zur Prüfung

Im AEAD-Betrieb nimmt die Verschlüsselung Nachricht, Associated Data, Schlüssel und Nonce entgegen und liefert Chiffrat plus Tag. Die Entschlüsselung berechnet den erwarteten Tag, vergleicht in konstanter Zeit und gibt Klartext erst bei Erfolg frei.

Für Verschlüsselung darf ein Schlüssel-Nonce-Paar nur einmal vorkommen. Eine andere Taglänge eröffnet keinen neuen Nonce-Raum. Wiederverwendung zeigt sofort die bitweise Differenz zweier Nachrichten und ermöglicht im beschriebenen Fall die Rückgewinnung internen Zustands. Ein Nonce darf öffentlich oder vorhersagbar sein; er muss unter dem Schlüssel eindeutig bleiben.

Für AEGIS-128L und AEGIS-128X nennt der RFC bei zufälligen Nonces bis zu 2^48 Nachrichten pro Schlüssel und ungefähr 2^-33 Kollisionswahrscheinlichkeit. Bei AEGIS-256 und AEGIS-256X sieht die Analyse keine praktische Grenze. Das bewertet zufällige Kollisionen und erlaubt keine absichtliche Wiederholung.

Die zweite Pflicht betrifft die Ausgabe. Scheitert die Authentifizierung, dürfen weder ungeprüfter Klartext noch falscher oder berechneter Tag ausgegeben werden; der Klartextpuffer ist zu überschreiben. Übergibt eine Pipeline vorher Teilbytes an Parser, Protokollierung, Callback oder Datenbank, ist die Schranke trotz späterem Fehler durchbrochen.

Ein Operationsnachweis verbindet deshalb Rolle, Variante, Taglänge, Schlüsselkennung, Nonce-Zuteilung, eindeutige AD-Kodierung, Prüfergebnis und sämtliche vorgezogenen Nebenwirkungen. Ein Tag prüft Bits unter einem Schlüssel; er kontrolliert nicht die Architektur, die womöglich bereits gehandelt hat.

Der Strommodus verwirft den Nachweis absichtlich

Die Stromfunktion verschlüsselt eine Nullfolge ohne Associated Data und verwirft den Tag. Die Finalisierung kann entfallen. Zurück bleibt ein Schlüsselstrom, keine authentifizierte Nachricht.

Das ist ein legitimer Dienst, sofern die übergeordnete Konstruktion ihn als solchen behandelt. Problematisch wird die Vererbung des Namens. Telemetrie bezeichnet aegis_stream() und aegis_encrypt() gleichermaßen als „AEGIS-geschützt“. Eine Migration behält das Algorithmusfeld, wechselt aber die Funktion. Eine spätere Gruppe vermutet einen Tag in einer anderen Schicht. Es gibt keinen: Er wurde definitionsgemäß verworfen.

Der Strom benötigt eigenen Schlüsselzweck, eigenen Nonce-Bereich und einen Typ „nicht authentifizierter Schlüsselstrom“. Liefert eine andere Konstruktion Integrität, muss der Nachweis diese Konstruktion, ihre Reihenfolge und ihre Freigabesperre nennen.

Der MAC besitzt die einzige Ausnahme

Die MAC-Funktion absorbiert Daten und erzeugt 128- oder 256-Bit-Tags. Nur sie darf laut RFC dasselbe (Schlüssel, Nonce)-Paar für verschiedene Eingaben verwenden.

Die Ausnahme gehört zur Funktion, nicht zur ganzen AEGIS-Familie. Eine gemeinsame Nonce-Richtlinie kann sie in die Verschlüsselung tragen. Der kryptografische Kern erkennt den Befugnisfehler nicht und berechnet weiter.

Auch der MAC-Tag hat negative Grenzen. Bei bekanntem Schlüssel lassen sich Eingaben mit Zustandskollisionen konstruieren, weshalb er nicht als Hash dienen darf. Weil keine gleichmäßige Zufallsverteilung garantiert ist, darf er nicht zur Schlüsselableitung verwendet werden. Seine Länge macht ihn weder zum Inhaltsdigest noch zum neuen Geheimnis.

Trennung sollte ausführbar sein: rollenfeste Schlüssel-IDs, verschiedene Ableitungslabels, getrennte Nonce-Zuteiler und Ablehnung eines AEAD-Schlüssels an STREAM- oder MAC-Schnittstellen. Erinnerung in einer Dokumentation ersetzt keine Kontrolle.

Taglänge und Associated Data bleiben Protokollentscheidungen

Ein 128-Bit-Tag bietet im beschriebenen Binding-Spiel ungefähr 64 Bit Key-Commitment-Sicherheit, ein 256-Bit-Tag etwa 128 Bit. Der Codepunkt sagt nicht, welche Länge aktiv war.

Die Eigenschaft hängt außerdem von der Kontrolle über Associated Data ab. AEGIS ist im eingeschränkten Fall vollständig bindend, wenn der Angreifer diese Daten nicht kontrollieren kann. Bei veränderbaren Associated Data erlaubt die zitierte Analyse, mehrere Schlüssel effizient zu finden, die dasselbe authentifizierte Chiffrat prüfen. Ein Protokoll mit stärkerem Bedarf kann die Daten mit einer passenden kollisions- und präbildresistenten Funktion hashen oder ihre eindeutige Kodierung unter den genannten Bedingungen an das info-Feld einer KDF binden.

Das sind Entscheidungen oberhalb des Primitivs. Das Protokoll muss Felder, Serialisierung, Kontrolle und gewünschte Eigenschaft benennen. Die Chiffre authentifiziert die empfangenen Bits, nicht deren organisatorische Bedeutung.

Testvektoren enden vor der Verwahrung

Die umfangreichen Vektoren in RFC 10032 zeigen, dass eine Implementierung feste Eingaben richtig transformiert. Interoperabilitätstests zeigen Übereinstimmung. Sie beweisen nicht, dass Produktion die richtige Rolle rief oder den Fehlerpfad abdichtete.

Negative Tests sollten Rollenverwechslung erzwingen: fremde Rollenschlüssel ablehnen; Verschlüsselungs-Nonce trotz anderer Taglänge wiederholen; die MAC-Ausnahme vom AEAD-Zuteiler isolieren; Stromausgabe als nicht authentifiziert typisieren; Chiffrat, Tag und AD beschädigen und keinerlei Klartext oder Wirkung beobachten; MAC-Tags an Hash- und KDF-APIs zurückweisen; geladenes Binary und CPU-Pfad prüfen; Zähler nach Rolle trennen.

Schutz gegen Zeit-, Leistungs- und Fehlerinjektionsangriffe hängt vom wirklichen AESRound und Bedrohungsmodell ab. Dass ephemere Schlüssel nach der Initialisierung gelöscht werden können, beweist nicht, dass Compiler und Bibliothek es tun. Das bleibt Running-Code-Evidenz.

Ein minimaler Rollenbeleg verbindet Zweck, Bedrohungsmodell, Rolle, Variante, Parallelgrad, Taglänge, Schlüsselidentität und -zweck, Nonce-Namespace und Zuteilung, AD-Schema, Bibliotheksversion und Laufzeitpfad, Prüfung, Löschung, Ausgabesperre, Live-Zähler und Anwendungsentscheidung.

Lu Hengs Lehre der minimalen Anfangsspezifikation erlaubt ein gemeinsames Primitiv, ohne ihm die Entscheidungen seiner Nutzer zu übertragen. Das Register benennt, die Bibliothek führt eine Rolle aus, das Protokoll strukturiert, die Anwendung genehmigt die Folge. Die Disziplin der Realitätsebenen verhindert, dass RFC, Test oder Tag die Autorität der nächsten Schicht übernimmt.

RFC 10032 zeigt somit: Gemeinsame Mechanik vereinigt keine Pflichten. Der Name blieb gleich; die Belege müssen getrennt bleiben.

Quellen