Dlaczego dłuższy klucz Blowfish nie naprawia bloku 64-bitowego

Profil VPN oferuje Blowfish z kluczem 448-bitowym, a ktoś proponuje użycie najdłuższego klucza, aby zachować szyfr. Długość klucza jest realna, ale to niewłaściwa liczba do optymalizacji. Blowfish przekształca bloki 64-bitowe niezależnie od długości klucza, a to szerokość bloku ogranicza, ile ruchu jeden klucz może bezpiecznie chronić. Wykonaj poniższe kontrole po kolei i zatrzymaj się na pierwszej, która oczyszcza usługę, ponieważ późniejszy krok nie naprawi wcześniejszego.

Sprawdź, co faktycznie negocjują strony

Odczytaj szyfr kanału danych z obu stron, a nie z profilu, który zamierzałeś wdrożyć. Konfiguracja klienta może wymieniać kilka szyfrów, a wybrany jest wynikiem negocjacji między dwiema implementacjami i ich wersjami. Zwiększ szczegółowość logów na połączeniu testowym i odczytaj wiersz kanału danych, który podaje szyfr i faktycznie zainicjowany rozmiar klucza.

Jeśli wynegocjowanym szyfrem jest AES-GCM lub ChaCha20-Poly1305, zatrzymaj się tutaj. Te konstrukcje używają bloku 128-bitowego i uwierzytelniają ładunek, więc poniższy argument o kolizjach 64-bitowych ich nie dotyczy.

Oddziel długość klucza od szerokości bloku

Blowfish akceptuje klucze od 32 do 448 bitów, a dokumentacja autora algorytmu podaje obie liczby osobno. Klucz jest sekretem; blok jest jednostką przekształcenia. Dłuższy sekret utrudnia zgadywanie i nie zmienia niczego w szerokości bloku przetwarzanego przez szyfr.

W trybie CBC szyfr jest stosowany do bloków o stałej szerokości, łańcuchowo z poprzednim blokiem szyfrogramu i dopełniany na końcu. Dla Blowfish ta szerokość wynosi 64 bity, czyli osiem bajtów. Harmonogram kluczy może być dowolnie duży; łańcuch nadal przesuwa się o osiem bajtów naraz.

Dlatego dłuższy klucz nie jest środkiem zaradczym. Adresuje atak siłowy na klucz, podczas gdy ryzyko kolizji poniżej jest właściwością szerokości bloku i trybu.

Zastosuj arytmetykę urodzin do rozmiaru bloku

Blok 64-bitowy ma skalę urodzinową około 2^32 bloków zaszyfrowanych jednym kluczem, zanim kolizje staną się prawdopodobne. Każdy blok niesie osiem bajtów, więc ta sama skala to około 2^35 bajtów, czyli 32 GiB danych pod jednym kluczem.

Traktuj to jako skalę, nie jako limit. Kolizje są probabilistyczne, a to, czy któraś coś ujawni, zależy od trybu, wzorca ruchu i od tego, czy atakujący potrafi rozpoznać lub wpłynąć na otaczający tekst jawny. Pierwszy bajt powyżej 32 GiB nie jest zdarzeniem odszyfrowania, a pierwsze 32 GiB nie są certyfikowane jako bezpieczne.

Badacze Sweet32 zademonstrowali w 2016 roku praktyczne ataki na szyfry blokowe 64-bitowe, w tym scenariusz OpenVPN, w warunkach wymagających obserwacji i generowania ruchu. Ich opublikowane wartości domyślne i wersje oprogramowania to kontekst historyczny, a nie opis twojego wdrożenia.

Zdecyduj, czy ponowne użycie CBC ma tu znaczenie

W CBC powtórzony blok szyfrogramu oznacza, że dwa bloki tekstu jawnego różnią się znaną zależnością, ponieważ XOR łańcuchowy się znosi. Atakujący, który może obserwować szyfrogram i zna lub potrafi wpłynąć na jeden z tekstów jawnych, może odzyskać informacje o drugim. Klucz Blowfish nigdy nie jest do tego potrzebny.

Istotne pytania to więc, jak długo klucz pozostaje w użyciu, ile ruchu przechodzi pod nim i czy ktoś może ten ruch obserwować i kierować nim. Odnawianie kluczy zmniejsza liczbę bloków na klucz, ale interwał czasu nie jest limitem bajtów: zajęty tunel może przenieść znacznie więcej danych niż bezczynny w tej samej godzinie. Jeśli zachowujesz starszy szyfr, wyprowadź limit z konstrukcji i rzeczywistego wolumenu, a nie z okrągłej liczby.

Jeśli zmierzony wolumen na klucz pozostaje znacznie poniżej skali urodzinowej, ekspozycja jest mniejsza. Nadal nie jest zerowa i nadal jest powodem, by planować migrację, zamiast przestać się martwić.

Zastąp szyfr, a nie klucz

Przenieś usługę na obsługiwany szyfr AEAD i potwierdź, że obie strony, ich wersje i ich backendy kryptograficzne mogą go wynegocjować. Dłuższy klucz Blowfish nie zmienia niczego istotnego, a zgadywanie nowej dyrektywy na jednym kliencie to sposób, w jaki działający tunel staje się zepsuty. Przetestuj zmianę na jednym kliencie i jednym serwerze, zanim dotkniesz reszty floty. Utrzymuj stary profil dostępny do wycofania, dopóki nowy szyfr nie przejdzie pełnego cyklu połączenia.

Utrzymuj weryfikację certyfikatów i uwierzytelnianie kont podczas zmiany. Odpowiadają na różne pytania: udane logowanie nie może poszerzyć bloku, a lepszy szyfr danych nie usprawiedliwia zaufania niewłaściwemu serwerowi.

Zakończ kontrolę, odczytując ponownie wynegocjowany szyfr na nowym połączeniu i potwierdzając, że stary szyfr nie jest już akceptowany. Jeśli strona nadal go oferuje, migracja nie jest zakończona, cokolwiek mówi profil po drugiej stronie.