AES-256 a OFB: wybierz pełną konstrukcję szyfru VPN

AES-256 i OFB odpowiadają na różne pytania, i właśnie tu przeglądy szyfrów zawodzą, gdy traktuje się je jako konkurencyjne opcje. Jedno nazywa szyfr blokowy z długością klucza; drugie opisuje, jak szyfr blokowy zamienia się w strumień dla dłuższej wiadomości. Podręcznik wyboru ochrony musi patrzeć na całą konstrukcję, w tym na to, jak odbiorca wykrywa zmodyfikowany pakiet.

Nazwij cztery części konstrukcji

Każdy przegląd sprowadza się do czterech pytań: jaki prymityw i długość klucza, jak przetwarza się nim wiadomości, jak odbiorca odrzuca nieautoryzowaną zmianę i jak protokół zarządza wejściami, kluczami i ich żywotnością. Lista znanych nazw odpowiada tylko na pierwsze. Drugie i trzecie to miejsce, w którym żyją rzeczywiste różnice, a czwarte to miejsce, w którym implementacje po cichu się rozchodzą. Zadaj je w tej kolejności i zapisz odpowiedzi.

OFB występuje wśród trybów poufności w publikacji NIST o trybach szyfrów blokowych, a poufność to wszystko, co oferuje. Protokół łączący tryb szyfrowania z osobnym MAC musi je poprawnie złożyć, a nazwa algorytmu nie dowodzi tego złożenia. Dlatego sama nazwa trybu nie może rozstrzygnąć decyzji o wdrożeniu.

Czwarte pytanie to takie, które operator może naprawdę sprawdzić w działającym systemie.

Preferuj konstrukcję uwierzytelnioną

Uwierzytelnione szyfrowanie daje poufność i integralność razem, a konstrukcje AEAD chronią też dane powiązane przed zmianą bez ich szyfrowania. To właściwość ochrony pakietów i nie ma nic wspólnego z tym, czy ktoś się pomyślnie zalogował.

Wskazówki Wskazówki Netgate dotyczące ustawień kryptograficznych OpenVPN wskazują dla kanału danych opcje AEAD, w tym AES-GCM, i to jest rodzaj obsługiwanej polityki, której należy przestrzegać. Używaj opcji obsługiwanych przez zainstalowane wydanie i klientów partnerskich, zamiast kopiować historyczny ranking trybów do nowego wdrożenia. Zgodność ze starymi, backendy kryptograficzne i obsługa offload ograniczają to, co jest naprawdę dostępne.

Obsługiwana konstrukcja bije sprytne złożenie za każdym razem.

Czytaj wynik negocjacji, nie ofertę

Szyfr na liście akceptowanych nie mówi nic o bieżącej sesji. Odczytaj wynegocjowaną ochronę kanału danych u klienta lub na bramie, a potem porównaj ją z polityką, którą chciałeś egzekwować. Konfiguracja, która nadal wymienia starą opcję dla jednego starego peera, jest decyzją o zgodności, a nie stwierdzeniem o sesji przed tobą.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Na bramie odpowiednim wyjściem jest asocjacja bezpieczeństwa albo szczegóły kryptograficzne połączenia, zależnie od platformy. W obu przypadkach oferta i wynik to różne fakty. Lista ze starą opcją dla jednego starego peera nie oznacza, że każda sesja jej używa, a sesja, która jej używa, jest tym, co trzeba było wiedzieć.

Zapisz oba fakty razem, z datą i wersją klienta.

Mierz tylko to, co da się porównać

Przepustowość zależy od sprzętu punktów końcowych, implementacji, akceleracji, rozmiarów pakietów i wybranej konfiguracji. Ani długość klucza, ani słowo OFB nie powiedzą ci, które wdrożenie będzie szybsze. Dlatego benchmark z innej strony jest w najlepszym razie wskazówką o sprzęcie, który ma ktoś inny. Twoje własne liczby zaczynają się od twoich własnych punktów końcowych.

Do autoryzowanego porównania utrzymuj punkty końcowe, obciążenie i wymaganą politykę na stałym poziomie oraz zapisz wynegocjowaną ochronę i wersje implementacji. Potem oceniaj wynik po tym, czy aplikacja skończyła, ile straciła i co robiły punkty końcowe, zamiast wnioskować o koszcie kryptografii z jednego testu prędkości. Liczba uzyskana w innych warunkach to opowieść, nie pomiar.

Jeśli stary peer nie spełnia polityki, to decyzja o zgodności dla jego właściciela.

Trzymaj integralność poza transakcją

Wyłączanie kontroli integralności albo akceptowanie niezweryfikowanego serwera nie jest optymalizacją wydajności i nie jest poprawką zgodności. Zmienia właściwość bezpieczeństwa, dla której wybrano konstrukcję. To samo dotyczy rozszerzania listy akceptowanych szyfrów, aż połączy się stary peer: połączenie się udaje, a polityka przestaje istnieć.

Zapisz zaakceptowaną konstrukcję i jej właściciela w podręczniku, aby następna zmiana zaczynała się od decyzji, a nie od preferencji.

Chcesz polityki, którą obie strony mogą wyegzekwować. Spór o to, która nazwa jest najsilniejsza, to inna rozmowa i zwykle kończy się bez decyzji.