AEGIS: szybkie szyfrowanie uwierzytelnione

AEGIS zaprojektowano specjalnie z myślą o maksymalnym wykorzystaniu sprzętowej akceleracji AES-NI, dzięki czemu osiąga przepustowość znacznie większą niż AES-GCM na współczesnych procesorach. Został zgłoszony do konkursu CAESAR, a później ujęty w projekcie standardu IETF dotyczącym użycia w TLS i QUIC.

AEGIS występuje w dwóch głównych wariantach: AEGIS-128 (klucz 128-bitowy, nonce 128-bitowy) i AEGIS-256 (klucz 256-bitowy, nonce 256-bitowy). Oba zapewniają odpowiednio 128-bitowe lub 256-bitowe tagi uwierzytelniające. AEGIS-128L to zoptymalizowany wariant zaprojektowany z myślą o wykorzystaniu szerszego zrównoleglenia potoku AES-NI we współczesnych procesorach.

W przeciwieństwie do AES-GCM, który używa AES jako elementu składowego w określonym trybie, AEGIS wykorzystuje wielokrotne wywołania funkcji rundy AES do utrzymywania i aktualizowania stanu wewnętrznego. Każdy krok szyfrowania wykonuje kilka rund AES, co pozwala wykorzystać równoległość na poziomie instrukcji w procesorach z szerokimi jednostkami wykonawczymi.

Na procesorach z AES-NI AEGIS-128L może osiągać przepustowość 100 Gb/s lub większą, podczas gdy AES-GCM zazwyczaj osiąga na tym samym sprzęcie 40–60 Gb/s. Ta przewaga wydajności wynosząca około 2–3 razy sprawia, że AEGIS jest atrakcyjny w scenariuszach szyfrowania sieciowego o dużej przepustowości.

AEGIS-128L używa ośmiu 128-bitowych słów stanu i przetwarza w każdym kroku dwa 256-bitowe bloki wiadomości, maksymalizując wykorzystanie potokowania AES-NI. Wariant "L" zapewnia większą przepustowość niż standardowy AEGIS-128 na procesorach, które mogą jednocześnie potokować wiele instrukcji AES-NI.

AEGIS zapewnia 128-bitową poufność oraz 128-bitowe lub 256-bitowe bezpieczeństwo autentyczności, zależnie od długości tagu. Analiza bezpieczeństwa nie wykazała w pełnej konstrukcji żadnych znanych ataków skuteczniejszych niż atak siłowy. Projekt zachowawczo wykorzystuje rundy AES, zapewniając znaczny margines bezpieczeństwa.

AEGIS został zaproponowany w projekcie standardu IETF (draft-irtf-cfrg-aegis-aead) do standaryzacji przez Crypto Forum Research Group. Projekt obejmuje AEGIS-128L, AEGIS-128 i AEGIS-256 oraz zawiera wektory testowe. Możliwość przyjęcia tych algorytmów w zestawach szyfrów TLS i QUIC jest obecnie aktywnie dyskutowana.

AEGIS nie ma użytecznego programowego mechanizmu zastępczego: bez AES-NI jego wydajność drastycznie spada, ponieważ każde wywołanie funkcji rundy AES staje się kosztowne. AEGIS należy wybierać tylko wtedy, gdy dostępność AES-NI jest zagwarantowana we wszystkich środowiskach wdrożeniowych, w tym na maszynach wirtualnych i w kontenerach.

ChaCha20-Poly1305 zaprojektowano jako szybki tryb AEAD dla środowisk bez AES-NI, takich jak mobilne procesory ARM sprzed ARMv8 oraz systemy wbudowane. Na współczesnych procesorach ARM64 z akceleracją AES AEGIS może być szybszy, ale ChaCha20-Poly1305 pozostaje bezpiecznym uniwersalnym wyborem, gdy możliwości sprzętowe są różne.

Aplikacje używające AEGIS muszą dokładnie przeanalizować swoje środowisko wdrożeniowe. W środowiskach bez AES-NI należy zaimplementować programowy fallback do AES-GCM lub ChaCha20-Poly1305. Zwinność kryptograficzna w warstwie negocjacji TLS obsługuje to automatycznie, gdy AEGIS jest oferowany jako preferowany zestaw szyfrów.

AEGIS jest obsługiwany przez implementację referencyjną AEGIS-cipher, OpenSSL 3.2+ za pośrednictwem Provider API oraz kilka eksperymentalnych stosów TLS. Oczekuje się, że jego popularność będzie rosnąć wraz z postępem projektu standardu IETF w kierunku statusu RFC oraz wraz ze wzrostem zapotrzebowania aplikacji o dużej przepustowości na wydajność większą niż oferowana przez AES-GCM.

Które stwierdzenie dotyczące wymagań sprzętowych AEGIS jest prawdziwe?

AEGIS zapewnia 2–3 razy większą przepustowość niż AES-GCM na sprzęcie z AES-NI, wykorzystując wiele funkcji rund AES w projekcie opartym na stanie. AEGIS-128L maksymalizuje równoległość potoku. Wymaga AES-NI i nie nadaje się do użycia, gdy możliwości sprzętowe są różne. Standaryzacja IETF na potrzeby TLS i QUIC jest w toku.