Velge AEAD for produksjonssystemer

AES-GCM er det riktige standardvalget for de fleste produksjonssystemer. Modusen er maskinvareakselerert via AES-NI på praktisk talt alle moderne x86- og ARM64-prosessorer, støttes bredt på tvers av TLS-stakker og kryptografibiblioteker, og har vært gjenstand for omfattende kryptanalyse og erfaring fra bruk i virkelige systemer.

AES-GCM bruker en nonce på 96 bit. Med tilfeldig genererte noncer nås bursdagsgrensen etter omtrent 2^32 meldinger med samme nøkkel. Da blir sannsynligheten for nonce-kollisjon ikke lenger ubetydelig. For systemer med stort volum er nonce-håndtering gjennom en teller, eller nøkkelbytte etter 2^32 meldinger, avgjørende.

ChaCha20-Poly1305 er det riktige valget når AES-NI ikke er tilgjengelig, eller når genereringen av noncer kan være upålitelig. Modusen er rask i programvare, konstanttidet av design og motstandsdyktig mot tidsbaserte sidekanaler, og er den obligatoriske ciphersuiten i TLS 1.3 for miljøer uten maskinvarestøtte for AES.

Når noncer kan bli gjenbrukt eller må genereres deterministisk, for eksempel i tilstandsløse tjenester eller ved nøkkelinnpakking, er AES-GCM-SIV (RFC 8452) det riktige valget. Modusen gir motstand mot feilbruk av nonce til en moderat ytelseskostnad sammenlignet med standard AES-GCM.

AEGIS-128L er det riktige valget når maksimal krypteringsgjennomstrømming er nødvendig, og det er garantert at AES-NI er tilgjengelig på alle målmiljøer. Nettverksutstyr med høy båndbredde, VPN-konsentratorer og systemer for lagringskryptering er svært godt egnet når AEGIS gir betydelige ytelsesfordeler fremfor AES-GCM.

AES-128 gir 128-biters sikkerhet, noe som anses som tilstrekkelig mot alle nåværende og forutsigbare trusler fra klassisk databehandling. AES-256 gir en ekstra margin mot fremtidige fremskritt og kreves av enkelte samsvarsrammeverk, for eksempel TOP SECRET-klassifisering under NSA Suite B. For de fleste applikasjoner er AES-128 tilstrekkelig og litt raskere.

AES-GCM bruker noncer på 96 bit, mens AES-GCM-SIV også bruker noncer på 96 bit. XSalsa20, som brukes i libsodium secretbox, bruker noncer på 192 bit, noe som gjør tilfeldig nonce-generering trygg for langt flere meldinger med samme nøkkel. Større noncer reduserer risikoen for utilsiktet gjenbruk i systemer med stort volum.

Bruk etablerte AEAD-biblioteker i stedet for å implementere primitiver direkte. libsodium tilbyr et enkelt AEAD-API (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt). Google Tink pakker inn AEAD-primitiver med nøkkelbytte og versjonering. TLS-biblioteker for det aktuelle språket håndterer AEAD automatisk for transportsikkerhet.

AES-CBC med en separat HMAC-SHA256, i EtM-rekkefølge, er akseptabelt, men regnes som eldre teknologi. Migrering til AES-GCM forenkler implementasjonen ved å erstatte to primitiver med én og eliminerer risikoen for feilaktig sammensetning. Data i ro som er kryptert med CBC-HMAC, bør krypteres på nytt med AES-GCM under planlagt nøkkelbytte.

AEAD-implementasjoner bør testes mot offisielle testvektorer fra NIST for AES-GCM og RFC 8439 for ChaCha20-Poly1305. Test alltid at feil ved verifisering av autentiseringstaggen fører til at dekrypteringen returnerer en feil, ikke delvis klartekst. Feilaktig feilhåndtering er en vanlig implementasjonsfeil.

Velg AES-GCM når AES-NI er tilgjengelig og noncene er unike. Velg ChaCha20-Poly1305 når AES-NI mangler eller nonce-genereringen er mindre pålitelig. Velg AES-GCM-SIV når gjenbruk av nonce er en bekymring. Velg AEGIS når maksimal gjennomstrømming med garantert AES-NI er prioritert. Velg aldri moduser uten AEAD for nye systemer.

AES-GCM er standardvalget. ChaCha20-Poly1305 dekker miljøer uten AES-NI. AES-GCM-SIV håndterer miljøer der nonce-håndteringen er usikker. AEGIS maksimerer gjennomstrømmingen når AES-NI er garantert. Bruk biblioteker som libsodium eller Tink i stedet for å sette sammen primitiver manuelt. Test alltid mot offisielle testvektorer, og kontroller at autentiseringsfeil håndteres riktig.