Výzkumná skupina IRTF popsala v RFC 10032 čtyři varianty šifry AEGIS
Dokument z dílny Crypto Forum Research Group popisuje čtyři šifry postavené na jediném kole AES. Proti AES-GCM slibují vyšší propustnost na procesorech s instrukcemi AES a mírnější limity na počet zpráv zašifrovaných jedním klíčem. Standardem IETF se tím ale nestávají.
Dokument RFC 10032 nese datum září 2026 a v historii konceptu je zapsaný jako vydaný 18. září. Podepsali ho Frank Denis z Fastly a Samuel Lucas jako samostatný přispěvatel. Na 64 stranách popisuje čtyři šifry: AEGIS-128L, AEGIS-256, AEGIS-128X a AEGIS-256X.
Všechny čtyři jsou AEAD, tedy autentizované šifrování s přidruženými daty. Jedním průchodem zašifrují zprávu a zároveň spočítají ověřovací značku, která pokryje i data poslaná vedle šifrovaného textu – hlavičky paketu, číslo relace. Dnešní protokoly používají hlavně AES-GCM a ChaCha20-Poly1305; AEGIS míří na totéž místo.
Jedno kolo AES místo celé šifry
Základem je funkce AESRound z FIPS 197, tedy jediné kolo AES se čtyřmi kroky. AEGIS z něj skládá vnitřní stav, u základních variant dlouhý 768 nebo 1024 bitů a žádná varianta nepotřebuje inverzní operaci. Procesory s instrukcemi AES dělají to kolo v hardwaru, a právě odtud má rodina svou rychlost.
Ze stavby plynou dvě vlastnosti, na kterých si RFC dává záležet. Únik vnitřního stavu neprozradí klíč ani předchozí stavy, což u většiny konstrukcí postavených na AES neplatí. A protože žádný klíčový rozvrh neexistuje a klíč potřebuje jen inicializační funkce, může ho implementace přepsat nulami dřív, než se zašifruje první bajt – útok na obsah paměti po studeném restartu pak nemá co najít.
Nonce se smí volit náhodně
Nonce je jednorázová hodnota, kterou se šifra odlišuje mezi zprávami pod týmž klíčem. U AES-GCM se počet zpráv s náhodně voleným nonce hlídat musí, a právě proti tomu se nové RFC v úvodu vymezuje.
AEGIS-256 a AEGIS-256X mají nonce dlouhý 256 bitů a podle RFC u nich náhodná volba nemá praktický strop. U AEGIS-128L a AEGIS-128X se stejným klíčem bezpečně projde 248 zpráv s pravděpodobností kolize kolem 2-33; dokument se odvolává na oddíl 8 doporučení NIST SP 800-38D. Zákaz opakování ale platí dál a je tvrdý: stejná dvojice klíče a nonce odhalí bitový rozdíl obou zpráv okamžitě, i kdyby se lišila délka značky.
Značka vázaná na klíč
Druhá věc, na které si autoři zakládají, se jmenuje committing security. U AES-GCM umí útočník vyrobit šifrový text, který se ověří pod několika různými klíči, a tím zrychlit hádání hesla na binární hledání; publikovaný útok se označuje jako partitioning oracle. U AEGIS se podle RFC očekává, že nalezení dvou různých dvojic klíče a nonce ke stejné trojici dat vyjde na 264 pokusů, když je značka dlouhá 128 bitů, a na 2128 u značky dvojnásobné délky.
Text u toho přiznává mez, kterou by šlo snadno přejít. Plně vázaná je šifra jen tam, kde útočník nemůže sahat na přidružená data; když na ně dosáhne, dají se násobné klíče najít efektivně. Protokolům, kterým to vadí, dokument radí prohnat přidružená data hašovací funkcí a teprve výsledek předat šifře.
Dvě varianty navíc pro široké registry
Písmeno X v názvu znamená paralelní režim pro procesory s vektorovými instrukcemi AES. AEGIS-128X2 zpracuje 512 bitů naráz proti 256 bitům základní varianty a drží stav dvojnásobné velikosti, 2048 bitů; u AEGIS-128X4 je to 1024 bitů na průchod a 4096 bitů stavu. Se stupněm paralelismu 1 jsou obě X varianty totožné se svými předlohami, což si podle RFC může implementace zjednodušit.
Doporučení kolem nich je opatrné. Výchozí volbou mají zůstat AEGIS-128L a AEGIS-256, paralelní režim má protokol sáhnout jen tehdy, když se na konkrétní variantě shodnou obě strany, a implementace ho nemusí obsahovat vůbec.
Standard to není
RFC má kategorii Informational a vyšlo proudem IRTF, ne IETF. Poslední odstavec úvodu to říká natvrdo: dokument zachycuje shodu skupiny Crypto Forum Research Group, není produktem IETF a není standard. Tutéž kategorii nese i RFC 10042 o postkvantových výměnách klíčů pro SSH: ani jeden z těch dokumentů nikomu nic nepředepisuje.
IANA přesto čísla přidělila. V registru AEAD Algorithms drží AEGIS šest položek, 32 až 37 – oba paralelní režimy mají stupeň 2 a 4 zapsaný zvlášť a v registru TLS Cipher Suites stojí TLS_AEGIS_256_SHA512 pod kódem 0x1306 a TLS_AEGIS_128L_SHA256 pod 0x1307. Obě položky mají ve sloupci Recommended písmeno N a jako pramen uvedený koncept z roku 2023; u zápisů v registru AEAD je odkaz na osmnáctou revizi konceptu, ne na číslo nového RFC. Knihovna libaegis mezi uživatele těch šifrových sad počítá picotls, server h2o a Fizz, implementaci TLS 1.3 od Facebooku.
Co v soutěži CAESAR vlastně vyhrálo
Úvod RFC píše, že mezi finalisty byla pro kategorii výkonných aplikací vybrána jako vítěz AEGIS-128. Stránka soutěže to podává jinak: v portfoliu pro druhý případ užití vede vedle sebe AEGIS-128 a OCB, a to výslovně v abecedním pořadí a bez preference. Dvojice vítězů tedy, ne jeden. Popsali AEGIS Hongjun Wu a Bart Preneel a specifikace se drží verze 1.1, protože starší znění jejich práce mělo jinou závěrečnou funkci.
Kolik ta rychlost dělá, se z dokumentu nedozvíte. Stojí v něm, že výkon na procesorech s instrukcemi AES výrazně převyšuje AES-GCM a že i softwarové implementace bez nich bývají rychlejší, jen méně výrazně; jediné číslo k tomu chybí. Měření v libaegis jsou zveřejněná jako obrázky grafů, takže se z nich žádná hodnota přečíst nedá.
Koncept šel do CFRG 5. srpna 2022, poslední revize označená osmnáctkou je z 5. října 2025 a na vydání se čekalo dalších jedenáct měsíců. Původní specifikaci text rozvádí o volitelné 256bitové značky a k tomu popisuje použití AEGIS jako proudové šifry a čtyři podoby autentizačního kódu AEGISMAC.