AEAD

AEAD (angl. Authenticated Encryption with Associated Data, česky autentizované šifrování s přidruženými daty) je druh symetrického šifrování, který v jediné operaci zajistí důvěrnost zprávy i ověření, že zprávu nikdo cestou nezměnil. Kromě šifrovaných dat chrání i další údaje, které musí zůstat čitelné (hlavičky paketů, čísla záznamů, identifikátory), takže ani ty nelze nepozorovaně podvrhnout. Výsledkem šifrování je šifrovaný text a krátká autentizační značka (tag). Při dešifrování se značka nejprve ověří a pokud nesedí, příjemce nedostane vůbec nic, jen chybu. AEAD je dnes výchozím způsobem šifrování dat v síťových protokolech (TLS 1.3, QUIC, WireGuard, SSH) i v moderních kryptografických knihovnách.

Klíčové údaje
Plný název	Authenticated Encryption with Associated Data
Zajišťuje	důvěrnost, integritu dat a autenticitu původu (u symetrického klíče)
Vstupy šifrování	klíč, nonce, otevřený text, přidružená data (AD)
Výstupy	šifrovaný text + autentizační značka (typicky 128 bitů)
Nejpoužívanější algoritmy	AES-GCM, ChaCha20-Poly1305, AES-CCM
Hlavní standardy	RFC 5116, NIST SP 800-38C a 800-38D, RFC 8439, RFC 8452, NIST SP 800-232 (Ascon)
Povinné v	TLS 1.3, QUIC, WireGuard
Nejčastější chyba	opakované použití stejné nonce se stejným klíčem

Proč samotné šifrování nestačí

Klasické šifrovací režimy, například blokové šifry v režimu CTR nebo CBC či proudové šifry, skrývají obsah zprávy, ale nijak nehlídají, zda s ní někdo nemanipuloval. Příjemce dešifruje cokoli, co dostane, a výsledek považuje za platný. Tato vlastnost se nazývá tvárnost (malleability).

Názorný příklad: banka šifruje platební příkaz v režimu CTR, kde se šifrovaný text vytváří XORem otevřeného textu s proudem klíče. Útočník šifru prolomit nedokáže, ale ví, že na pevné pozici ve zprávě je částka „100“. Když v šifrovaném textu překlopí přesně ty bity, které odpovídají rozdílu mezi znaky „1“ a „9“, příjemce po dešifrování přečte „900“. Útočník přitom nezná klíč ani zbytek zprávy. Stejně lze přepsat číslo účtu nebo příznak „admin=0“ na „admin=1“.

U režimu CBC je manipulace o něco složitější, ale možná také: změna bloku šifrovaného textu cíleně změní následující blok otevřeného textu. Navíc server, který dešifruje neověřená data a reaguje na ně (například chybou o neplatném zarovnání), se může stát orákulem, s jehož pomocí útočník rozšifruje celou zprávu. Na tom stojí útoky typu padding oracle, které podrobně popisuje článek o blokové šifře a vycpávce.

Šifrování proto potřebuje autentizační kód zprávy (MAC), kontrolní údaj z dat a tajného klíče, který útočník bez klíče nedopočítá. AEAD obě funkce spojuje do jednoho celku, který se nedá použít „napůl“.

Historie: od skládání šifry a MAC k AEAD

Až do přelomu tisíciletí si návrháři protokolů skládali šifru a MAC sami a každý jinak:

Konstrukce	Postup	Kde se používala	Hodnocení
Encrypt-and-MAC	MAC se počítá z otevřeného textu, šifruje se zvlášť	SSH (původní návrh)	MAC může prozradit informace o obsahu, obecně nebezpečné
MAC-then-Encrypt	nejdřív MAC z otevřeného textu, pak se zpráva i MAC zašifrují	SSL a TLS do verze 1.2 (režim CBC)	příjemce musí dešifrovat dřív, než ověří, zdroj útoků padding oracle
Encrypt-then-MAC	nejdřív šifrování, pak MAC ze šifrovaného textu	IPsec ESP, TLS s rozšířením RFC 7366	obecně bezpečné, neověřená data se vůbec nedešifrují

Klíčovou práci publikovali v roce 2000 Mihir Bellare a Chanathip Namprempre (konference Asiacrypt). Formálně dokázali, že při obecném skládání je bezpečné jen Encrypt-then-MAC, zatímco zbylé dvě varianty mohou být bezpečné jen díky vlastnostem konkrétních algoritmů. Hugo Krawczyk v roce 2001 analyzoval pořadí v SSL a ukázal, proč je MAC-then-Encrypt křehké. Praxe mu dala za pravdu: útoky Lucky Thirteen (2013) a POODLE (2014) zneužily právě to, že TLS v režimu CBC ověřovalo MAC až po dešifrování.

Pojem přidružená data zavedl Phillip Rogaway v roce 2002. Všiml si, že protokoly potřebují chránit i údaje, které šifrovat nelze nebo nechtějí. Ve stejné době vznikly první režimy, které šifrování a autentizaci spojují přímo v jednom algoritmu: OCB (Rogaway, 2001), CCM (2002, později NIST SP 800-38C) a GCM (McGrew a Viega, standardizován jako NIST SP 800-38D v roce 2007). V roce 2008 sjednotilo programové rozhraní AEAD RFC 5116 a TLS 1.2 získalo šifrovací sady s AES-GCM (RFC 5288).

Soutěž CAESAR (2014–2019) vybrala portfolio nových AEAD šifer (mimo jiné Ascon, AEGIS-128 a OCB). Ascon pak zvítězil i v soutěži NIST pro zařízení s omezeným výkonem a v srpnu 2025 byl standardizován jako NIST SP 800-232.

Co jsou přidružená data

Přidružená data (Associated Data, AD, někdy AAD) jsou údaje, které se nešifrují, ale jsou chráněny autentizační značkou. Příjemce je musí mít k dispozici (obvykle je zná z kontextu nebo jsou součástí zprávy v otevřené podobě) a při dešifrování je předá algoritmu. Pokud se liší byť jediným bitem od toho, co použil odesílatel, ověření značky selže.

Některé údaje musí číst zařízení po cestě nebo příjemce ještě před dešifrováním (směrování, délka, číslo záznamu), jiné nejsou tajné, ale jejich záměna by byla nebezpečná.

Praktické příklady:

• TLS 1.3: přidruženými daty je pětibajtová hlavička záznamu (typ obsahu, verze a délka). Útočník tak nemůže změnit délku nebo typ záznamu, aniž by to příjemce poznal.
• IPsec ESP s AES-GCM (RFC 4106): přidruženými daty je identifikátor bezpečnostní asociace (SPI) a pořadové číslo paketu. To zabraňuje přesunu paketu do jiného tunelu a spolu s kontrolou pořadových čísel chrání před replay útokem.
• QUIC: přidruženými daty je hlavička paketu včetně čísla paketu.
• Šifrování v databázi: při šifrování citlivého sloupce (např. rodného čísla) se jako přidružená data použije název tabulky, sloupce a ID řádku. Útočník s přístupem do databáze pak nemůže zkopírovat šifrovanou hodnotu z jednoho záznamu do jiného, protože u cizího ID řádku dešifrování selže. Stejný princip používají cloudové služby pro správu klíčů pod názvem encryption context.

Přidružená data mohou být i prázdná. Pak AEAD funguje jako prosté autentizované šifrování.

Jak AEAD funguje

Rozhraní je u všech algoritmů stejné (RFC 5116), liší se jen vnitřní konstrukce.

Šifrování:

1. Odesílatel má sdílený tajný klíč (typicky 128 nebo 256 bitů), dohodnutý například pomocí výměny klíče.
2. Pro každou zprávu zvolí nonce (number used once), hodnotu podobnou inicializačnímu vektoru, která se pro daný klíč nesmí nikdy opakovat. Nonce není tajná.
3. Algoritmu předá klíč, nonce, otevřený text a přidružená data.
4. Algoritmus zašifruje otevřený text a zároveň z šifrovaného textu a přidružených dat vypočte autentizační značku.
5. Odesílatel odešle nonce, přidružená data, šifrovaný text a značku.

Dešifrování:

1. Příjemce předá algoritmu klíč, přijatou nonce, přidružená data, šifrovaný text a značku.
2. Algoritmus značku znovu vypočte a porovná ji s přijatou (v konstantním čase, aby porovnání neprozradilo nic časováním).
3. Pokud se značky shodují, vrátí otevřený text. Pokud ne, vrátí pouze chybu a žádná část otevřeného textu se nesmí dostat ven.

Režie oproti otevřenému textu je jen nonce a značka (u AES-GCM obvykle 12 + 16 bajtů). Uvnitř se většinou kombinuje proudové šifrování s rychlou autentizační funkcí: AES-GCM spojuje AES v režimu CTR s funkcí GHASH, ChaCha20-Poly1305 šifru ChaCha20 s autentizátorem Poly1305 a AES-CCM režim CTR s CBC-MAC.

Přehled algoritmů

Algoritmus	Klíč	Nonce	Značka	Kde se používá
AES-GCM	128, 192 nebo 256 bitů	96 bitů (doporučeno)	128 bitů (zkrácené až na 96 a méně jen výjimečně)	TLS 1.2 a 1.3, IPsec, QUIC, SSH, cloudové služby, šifrování úložišť
ChaCha20-Poly1305	256 bitů	96 bitů	128 bitů	TLS 1.3, QUIC, WireGuard, OpenSSH, Signal, mobilní zařízení bez akcelerace AES
XChaCha20-Poly1305	256 bitů	192 bitů	128 bitů	libsodium, aplikace s náhodnými nonce, WireGuard (cookies)
AES-CCM	128 nebo 256 bitů	56–104 bitů (7–13 bajtů)	32–128 bitů	Wi-Fi WPA2/WPA3 (CCMP), Bluetooth LE, Zigbee, TLS pro IoT
AES-OCB (OCB3)	128, 192 nebo 256 bitů	až 120 bitů (běžně 96)	až 128 bitů	OpenPGP (RFC 9580), aplikace s důrazem na výkon
AES-GCM-SIV	128 nebo 256 bitů	96 bitů	128 bitů	systémy, kde nelze zaručit unikátní nonce
Ascon-AEAD128	128 bitů	128 bitů	128 bitů	IoT, čipové karty, senzory a jiná zařízení s omezeným výkonem (NIST SP 800-232)

AES-GCM je nejrozšířenější, protože moderní procesory mají instrukce pro AES i násobení v Galoisově tělese (AES-NI, PCLMULQDQ) a dosahují rychlosti několika gigabajtů za sekundu. ChaCha20-Poly1305 je rychlejší v čistě softwarové implementaci a přirozeně odolná proti časovým útokům postranním kanálem. OCB byl dlouho omezován patenty, které autor v roce 2021 opustil. XChaCha20-Poly1305 zatím není RFC, existuje jen jako návrh IRTF, ale je široce implementována.

Opakování nonce: katastrofa místo drobné chyby

Bezpečnost AES-GCM, ChaCha20-Poly1305 i AES-CCM stojí na tom, že se dvojice klíč a nonce nikdy nepoužije dvakrát. Opakování má dva důsledky:

• Únik obsahu: obě zprávy se zašifrují stejným proudem klíče, takže XOR jejich šifrovaných textů se rovná XORu otevřených textů. Se znalostí jedné zprávy útočník přečte druhou.
• Ztráta autentizace: u GCM útočník ze dvou zpráv se stejnou nonce sestaví rovnici, jejímž řešením je tajný autentizační klíč H funkce GHASH. Antoine Joux tento útok popsal v roce 2006 v připomínkách k návrhu standardu NIST a vžil se pro něj název „forbidden attack“. S klíčem H útočník dokáže padělat libovolné zprávy, které příjemce přijme jako pravé. U Poly1305 se podobně prozradí jednorázový autentizační klíč.

Nejde o teoretickou hrozbu:

Rok	Incident	Co se stalo
2016	HTTPS servery s opakovanými nonce v GCM	Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky a Philipp Jovanovic při skenu internetu našli 184 HTTPS serverů, které nonce v AES-GCM opakovaly, a více než 70 000 serverů s náhodnými nonce ohroženými kolizí.
2017	KRACK	Útok Mathyho Vanhoefa na WPA2 přiměl zařízení vynulovat čítač nonce. U šifry GCMP tím útočník mohl kromě dešifrování i padělat pakety.
2018	EFAIL	Šifrované e-maily S/MIME a OpenPGP používaly neautentizované režimy CBC a CFB. Díky tvárnosti šlo do šifrovaného textu vložit HTML kód, který po dešifrování odeslal obsah zprávy útočníkovi.
2022	Samsung TrustZone	Úložiště klíčů telefonů Galaxy S8 až S21 (přibližně 100 milionů zařízení) umožňovalo opakování IV v AES-GCM, a tím získání hardwarově chráněných klíčů.
2023	Terrapin (CVE-2023-48795)	Útok na SSH zneužil manipulaci s pořadovými čísly při navazování spojení a dokázal nepozorovaně odstranit úvodní zprávy. Týkal se i režimu chacha20-poly1305@openssh.com. AEAD chrání jednotlivé zprávy, ale za správné použití pořadových čísel odpovídá protokol.

Odolnost proti zneužití nonce

Pro situace, kdy unikátnost nonce nelze spolehlivě zaručit (distribuované systémy bez společného čítače, šifrování klíčů, zařízení bez trvalé paměti), vznikly režimy odolné proti zneužití nonce (nonce-misuse resistant). Základní myšlenku konstrukce SIV (Synthetic IV) popsali Rogaway a Shrimpton v roce 2006: hodnota pro šifrování se odvodí z klíče, nonce, přidružených dat i celé zprávy.

Při opakování nonce u AES-SIV (RFC 5297) nebo AES-GCM-SIV (RFC 8452) útočník zjistí jen to, že byla dvakrát zašifrována totožná zpráva. Obsah ani autentizace se neprolomí. Cenou je nižší výkon (zpráva se zpracovává dvakrát) a nemožnost šifrovat proud dat průběžně, protože šifrování může začít až po přečtení celé zprávy.

Jiným přístupem je prodloužená nonce: XChaCha20-Poly1305 má 192bitovou nonce, u které je náhodná kolize i při obrovském počtu zpráv zanedbatelná. Nonce tak lze generovat generátorem pseudonáhodných čísel bez nutnosti udržovat čítač.

Limity použití klíče

Ani s unikátními nonce nelze jedním klíčem šifrovat neomezeně, protože s objemem dat roste útočníkova šance na úspěch. Standardy proto stanovují limity:

• NIST SP 800-38D omezuje u AES-GCM s náhodnými 96bitovými nonce počet šifrování jedním klíčem na 2^32, aby pravděpodobnost kolize nonce zůstala zanedbatelná.
• TLS 1.3 (RFC 8446) doporučuje u AES-GCM obnovit klíče nejpozději po přibližně 2^24,5 záznamech plné velikosti (zhruba 24 milionů). U ChaCha20-Poly1305 je limit tak vysoký, že se v praxi neuplatní. Obnovu zajišťuje mechanismus KeyUpdate.
• QUIC (RFC 9001) navíc omezuje počet neúspěšných pokusů o ověření paketu.

Hlídání těchto limitů patří do správy klíčů: klíče rotujte podle objemu dat, ne jen podle času.

AES-GCM a ChaCha20-Poly1305 navíc nejsou „key-committing“: lze sestrojit šifrovaný text, který se platně dešifruje dvěma různými klíči (útok invisible salamanders, 2018). Při běžném přenosu to nevadí, u systémů s více příjemci nebo hlášením zneužití ano.

Kde je AEAD povinné

• TLS 1.3 (RFC 8446, 2018): všechny šifrovací sady jsou výhradně AEAD (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, AES-128-CCM a AES-128-CCM-8). Režimy CBC, RC4 a samostatný MAC byly odstraněny. Nonce záznamu vzniká XORem pořadového čísla se statickým IV, takže se nikdy neopakuje.
• QUIC a HTTP/3 (RFC 9001): přebírá AEAD algoritmy z TLS 1.3 a chrání jimi každý paket.
• WireGuard: pevně používá ChaCha20-Poly1305 s 64bitovým čítačem jako nonce, bez možnosti volby jiné šifry.
• SSH: OpenSSH od roku 2014 nabízí režim chacha20-poly1305@openssh.com (dnes první v pořadí preferencí) a také aes128-gcm@openssh.com a aes256-gcm@openssh.com.
• Wi-Fi WPA2 a WPA3: CCMP (AES-CCM), ve WPA3 Enterprise GCMP-256.

Doporučení pro vývojáře

• Nikdy neskládejte šifru a MAC sami a nepište vlastní implementaci AEAD. Používejte vysokoúrovňové knihovny: libsodium (crypto_aead_xchacha20poly1305_ietf_encrypt nebo crypto_secretbox), Google Tink, AEAD rozhraní ve standardních knihovnách (Go crypto/cipher, Java Cipher s AES/GCM/NoPadding, .NET AesGcm, Web Crypto AES-GCM).
• Rozhodněte, jak budete tvořit nonce. Čítač je bezpečný, pokud jej spolehlivě uchováte i přes restarty a nikdy jej nesdílí dva odesílatelé se stejným klíčem. Náhodné nonce jsou jednodušší, ale u 96bitových nonce dodržujte limit 2^32 zpráv na klíč. Pokud si nejste jisti, volte XChaCha20-Poly1305 nebo AES-GCM-SIV.
• Nikdy nepoužívejte pevnou nebo nulovou nonce, ani „jen pro testy“.
• Nepracujte s otevřeným textem před ověřením značky. Při šifrování velkých souborů nevypisujte, neparsujte ani neukládejte data, dokud ověření neskončí úspěchem. Pro proudová data použijte konstrukce, které dělí data na samostatně autentizované bloky (např. crypto_secretstream v libsodium).
• Využijte přidružená data pro vše, co určuje význam zprávy: ID záznamu, uživatele, verzi formátu, směr komunikace. Brání to záměně jinak platných šifrovaných textů.
• Nezkracujte značku pod 128 bitů bez vážného důvodu.
• Při chybě ověření vracejte jednotnou chybu bez podrobností a v konstantním čase. Rozdílné chybové hlášky mohou vytvořit orákulum.
• Při auditu a penetračních testech hledejte režimy ECB, CBC nebo CTR bez MAC, porovnávání značek běžným ==, opakované nebo konstantní nonce a ruční skládání šifry a MAC. Takové nálezy jsou typickým zdrojem kryptografických útoků.

Zdroje

• Jirásek, P., Novák, L., Požár, J.: Výkladový slovník kybernetické bezpečnosti, 6. aktualizované vydání, Centrum kybernetické bezpečnosti, z.ú. / NÚKIB
• RFC 5116: An Interface and Algorithms for Authenticated Encryption
• NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC
• NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices
• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols
• RFC 8452: AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• Bellare, M., Namprempre, C.: Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm
• Böck, H. a kol.: Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS (2016)
• Shakevsky, A., Ronen, E., Wool, A.: Trust Dies in Darkness: Shedding Light on Samsung's TrustZone Keymaster Design (2022)
• libsodium: AEAD constructions