Jak wybrać odpowiedni IV (Wektor inicjalizacji) dla AES/CTR/NoPadding?

CTR security wymaga, aby nigdy ponownie używać IV do szyfrowania dwóch wiadomości z tym samym kluczem. W rzeczywistości jest to jeszcze bardziej surowsze: tryb CTR działa poprzez szyfrowanie kolejnych wartości licznika (IV jest tylko wartością początkową dla tego licznika), a odpowiednie bezpieczeństwo jest osiągane tylko wtedy, gdy ta sama wartość licznika nie jest używana dwukrotnie; oznacza to, że szyfrowanie wartości z IV faktycznie "zużywa" ciąg kolejnych wartości IV, które nie mogą być ponownie użyte z innym licznikiem. szyfrowanie.

Najprostszym sposobem na to jest użycie zabezpieczonego kryptograficznie generatora liczb losowych i utworzenie nowego 16-bajtowego losowego IV dla każdej wiadomości. Podkreślam "bezpieczeństwo kryptograficzne", ponieważ to ważne; podstawowy generator liczb losowych nie wystarczy. W Javie użyj java.util.SecureRandom. Z Win32 wywołaj CryptGenRandom(). Przy przypadkowym wyborze przestrzeń możliwego 128-bitowego IV jest na tyle duża, że kolizje są niezwykle nieprawdopodobne. Właśnie dlatego AES wykorzystuje 128-bitowe bloki (tak 128-bitowe IV).

Jednostka, która odszyfruje wiadomość, musi znać IV, więc musisz ją przechowywać razem z zaszyfrowaną wiadomością. To dodatkowe 16 bajtów. Rozumiem, że ten overhead jest tym, czego chcesz uniknąć, chociaż 16 bajtów to nie tyle za ciasteczko. Efektywna maksymalna długość pliku cookie zależy od przeglądarki internetowej, ale 4000 znaków wydaje się działać "wszędzie". 16-bajtowy IV, zakodowany w postaci znaków (np. z Base64), będzie używał około 22 znaków, tj. znacznie mniej niż 1% maksymalnego rozmiaru plików cookie: może stać Cię na to ?

Teraz możemy dostać funky i spróbować zmniejszyć długość IV poprzez trickery:

• Wygeneruj IV za pomocą funkcji hash: Po stronie serwera użyj licznika, który zaczyna się od 0 i jest zwiększany za każdym razem, gdy potrzebna jest nowa IV. Aby uzyskać IV, hashujesz licznik za pomocą odpowiedniej funkcji skrótu, np. SHA-256, i zachowujesz pierwsze 16 bajtów wartości skrótu. "Właściwości randomizacji" funkcja hash będzie wystarczająca, aby IV był wystarczająco losowy w odniesieniu do wymagań CTR. Wymaga to kryptograficznie bezpiecznej funkcji skrótu, stąd SHA-256 (unikaj MD5). Następnie wystarczy zapisać wartość licznika w pliku cookie, a licznik będzie krótszy niż 16 bajtów (np. jeśli masz nie więcej niż 4 miliardy klientów, licznik zmieści się w 4 bajtach). Istnieje jednak ukryty koszt: serwer (przypuszczam, że serwer wykonuje szyfrowanie w Twoim systemie) musi się upewnić że nigdy nie wykorzystuje ponownie wartości licznika, więc musi przechowywać" aktualny licznik " gdzieś w sposób, który utrzymuje się przez restart serwera, a także nie zawiedzie, jeśli skalujesz do kilku front-endów. To nie takie proste.

• Użyj zewnętrznej unikalnej wartości: możliwe, że plik cookie może być częścią kontekstu, który zapewnia wystarczającą ilość danych, aby wygenerować wartość, która będzie unikalna dla każdego szyfrowania. Na przykład, jeśli żądanie zawiera również (w przezroczystym) " identyfikator użytkownika", możesz użyć identyfikatora użytkownika jako źródła IV. Konfiguracja jest podobna do powyższej: dostajesz wszystkie te dane, wpychasz je do SHA-256, a pierwsze 16 bajtów wyjścia SHA-256 to IV, którego potrzebujesz. Działa to tylko wtedy, gdy dane te nie zmieniają się dla danej zaszyfrowanej wiadomości i jeśli są naprawdę unikalne. Jest to rzadkie zjawisko: na przykład "ID użytkownika" jest dobre tylko wtedy, gdy nigdy nie ma potrzeby ponownego szyfrowania nowej wiadomości dla tego samego użytkownika i jeśli nigdy nie ma możliwości, że identyfikator użytkownika jest ponowne użycie(np. Stary użytkownik rezygnuje, nowy przychodzi i wybiera teraz wolny identyfikator użytkownika).

Używanie losowego 16-bajtowego IV generowanego z kryptograficznie bezpiecznym PRNG jest nadal "bezpiecznym" sposobem, który polecam. Jeśli w pliku cookie znajdziesz mało miejsca, oznacza to, że zbliżasz się do limitu 4 kB, w którym to momencie możesz chcieć użyć kompresji (na danych przed szyfrowaniem; po szyfrowaniu kompresja jest bardzo mało prawdopodobna). Użyj zlib (w języku Java dostęp do zlib można uzyskać poprzez java.util.zip).

Warning: w tym wszystkim, nie mówię nic o tym, czy szyfrowanie plików cookie pomaga w zapewnieniu jakichkolwiek cech bezpieczeństwa, które próbujesz osiągnąć. Zazwyczaj, gdy potrzebne jest szyfrowanie, w rzeczywistości potrzebne jest zarówno szyfrowanie, jak i integralność, a następnie należy użyć trybu połączonego szyfrowania i integralności. Lookup GCM i CCM. Co więcej, szyfrowanie plików cookie jest głównie dobre dla jednego cel, który ma na celu uniknięcie kosztów przechowywania po stronie serwera trochę danych specyficznych dla użytkownika. Jeśli chcesz zaszyfrować plik cookie dla czegoś innego, np. aby uwierzytelnić ważnego użytkownika, robisz to źle: szyfrowanie nie jest właściwym narzędziem do tego.