Välja AEAD för produktionssystem

AES-GCM är rätt standardval för de flesta produktionssystem. Det maskinvaruaccelereras via AES-NI på i stort sett alla moderna x86- och ARM64-processorer, har brett stöd i TLS-stackar och kryptografiska bibliotek samt drar nytta av omfattande kryptoanalys och erfarenhet från användning i verkliga system.

AES-GCM använder en 96-bitars nonce. Med slumpmässigt genererade noncer nås birthday bound efter ungefär 2^32 meddelanden med samma nyckel. Därefter blir sannolikheten för en nonce-kollision inte längre försumbar. För system med stora datamängder är nonce-hantering med en räknare eller nyckelrotation efter 2^32 meddelanden nödvändig.

ChaCha20-Poly1305 är rätt val när AES-NI inte är tillgängligt eller när nonce-genereringen kan vara opålitlig. Algoritmen är snabb i programvara, konstanttidssäker till sin konstruktion (motståndskraftig mot tidsbaserade sidokanaler) och är den obligatoriska chiffersviten i TLS 1.3 för miljöer utan stöd för AES-maskinvara.

När noncer kan återanvändas eller måste genereras deterministiskt, till exempel i tillståndslösa tjänster eller vid nyckelinkapsling, är AES-GCM-SIV (RFC 8452) det rätta valet. Den ger motståndskraft mot nonce-missbruk till en måttlig prestandakostnad jämfört med vanlig AES-GCM.

AEGIS-128L är rätt val när maximal krypteringsgenomströmning krävs och det är garanterat att AES-NI finns på alla målmiljöer. Nätverksutrustning med hög bandbredd, VPN-koncentratorer och system för lagringskryptering är särskilt lämpliga användningsområden där AEGIS ger betydande prestandavinster jämfört med AES-GCM.

AES-128 ger 128-bitars säkerhet, vilket anses tillräckligt mot alla nuvarande och förutsebara hot från klassisk databehandling. AES-256 ger en större marginal mot framtida framsteg och krävs av vissa regelverk, till exempel TOP SECRET-klassificering enligt NSA Suite B. För de flesta program är AES-128 tillräckligt och något snabbare.

AES-GCM använder 96-bitars noncer, medan AES-GCM-SIV också använder 96-bitars noncer. XSalsa20 (som används i libsodium secretbox) använder 192-bitars noncer, vilket gör slumpmässig nonce-generering säker för betydligt fler meddelanden med samma nyckel. Längre noncer minskar risken för oavsiktlig återanvändning i system med stora datamängder.

Använd etablerade AEAD-bibliotek i stället för att implementera primitiver direkt. libsodium tillhandahåller ett enkelt AEAD-API (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt). Google Tink kapslar in AEAD-primitiver med nyckelrotation och versionshantering. Språkspecifika TLS-bibliotek hanterar AEAD automatiskt för transportsäkerhet.

AES-CBC med en separat HMAC-SHA256 (i EtM-ordning) är acceptabelt men föråldrat. Migrering till AES-GCM förenklar implementationen genom att ersätta två primitiver med en och eliminerar risken för felaktig sammansättning. Data i vila som är krypterad med CBC-HMAC bör krypteras om med AES-GCM vid planerad nyckelrotation.

AEAD-implementationer bör testas mot officiella testvektorer från NIST (för AES-GCM) och RFC 8439 (för ChaCha20-Poly1305). Testa alltid att verifieringsfel för autentiseringstaggen gör att dekrypteringen returnerar ett fel i stället för delvis dekrypterad klartext. Felaktig felhantering är en vanlig implementeringsbrist.

Välj AES-GCM när AES-NI finns och noncerna är unika. Välj ChaCha20-Poly1305 när AES-NI saknas eller noncerna är mindre tillförlitliga. Välj AES-GCM-SIV när nonceåteranvändning är ett problem. Välj AEGIS när maximal genomströmning med garanterad AES-NI är prioriterad. Välj aldrig lägen utan AEAD för nya system.

AES-GCM är standardvalet. ChaCha20-Poly1305 är avsett för miljöer utan AES-NI. AES-GCM-SIV hanterar miljöer där noncer inte kan garanteras vara säkra. AEGIS maximerar genomströmningen när AES-NI är garanterat. Använd bibliotek som libsodium eller Tink i stället för att sätta samman primitiver manuellt. Testa alltid mot officiella testvektorer och kontrollera att autentiseringsfel hanteras korrekt.