Dlaczego nie ' t używać szyfrowania EBC?
On 18 lutego, 2021 by adminUżywam Javy do generowania zaszyfrowanych ciągów i pojawia się to ostrzeżenie w czasie kompilacji:
Nie należy używać trybu szyfrowania EBC
Zastanawiam się więc, dlaczego nie powinienem używać EBC i czego mogę użyć zamiast tego ?
Komentarze
- Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
- Czy pracujesz przy powiększeniu?;)
Odpowiedź
Dlaczego nie powinienem używać szyfrowania EBC?
Głównym powodem nieużywania szyfrowania w trybie EBC jest to, że nie jest to semantycznie bezpieczny — to znaczy, samo obserwowanie zaszyfrowanego przez EBC tekstu zaszyfrowanego może spowodować wyciek informacji o tekście jawnym (nawet poza jego długością, co wszystkie schematy szyfrowania akceptujące dowolnie długie teksty jawne w pewnym stopniu wyciekną).
Specyficzne w ten sposób problem z trybem EBC polega na tym, że szyfrowanie tego samego bloku (8 lub 16 bajtów lub niezależnie od rozmiaru bloku podstawowego szyfru) tekstu jawnego w trybie ECB zawsze daje ten sam blok zaszyfrowanego tekstu. Dzięki temu osoba atakująca może:
- wykryć, czy dwie wiadomości zaszyfrowane przez EBC są identyczne;
- wykryć, czy dwie wiadomości zaszyfrowane przez EBC mają wspólny prefiks;
- wykryć, czy dwa zaszyfrowane przez EBC wiadomości mają inne wspólne podciągi, o ile są one wyrównane na granicach bloków; lub
- wykryć, czy (i gdzie) pojedyncza wiadomość zaszyfrowana przez EBC zawiera powtarzające się dane (takie jak długie ciągi spacji lub bajtów zerowych, powtarzające się pola nagłówka lub przypadkowo powtarzające się frazy w tekście).
Jest „fajna graficzna demonstracja tej słabości w Wikipedii, gdzie ten sam (surowy, nieskompresowany) obraz jest szyfrowany zarówno w trybie EBC, jak i semantycznie bezpieczny tryb szyfrowania (taki jak CBC, CTR, CFB lub OFB):
Chociaż ten scenariusz jest nieco sztuczny (zwykle nie szyfruje się takich surowych obrazów), ładnie ilustruje problem z trybem EBC: powtarzające się obszary obrazu wejściowego skutkują powtarzającymi się wzorami w zaszyfrowanym wyjściu, dzięki czemu wiele cech obrazu na dużą skalę pozostaje rozpoznawalnych pomimo szyfrowania. W rzeczywistości kryptoanalityk atakujący EBC- szyfrowanie oparte schemat prawdopodobnie szukałby takich wzorców w zrzucie szesnastkowym tekstu zaszyfrowanego, ale zasada jest taka sama.
Rzeczywistym przypadkiem tej słabości szyfrowania EBC przyczyniającego się do kompromitacji danych w świecie rzeczywistym jest podane przez wyciek bazy danych haseł Adobe z 2013 r., zgodnie z opisem w tej odpowiedzi . W tym przypadku jednym z elementów przyczyniających się do powagi wycieku było to, że zamiast poprawnie je zahaszować , firma Adobe zaszyfrowała hasła w trybie EBC. Umożliwiło to atakującym szybkie zlokalizowanie haseł współdzielonych przez wiele kont lub udostępnienie wspólnego prefiksu z innymi hasłami (takimi jak hasło1 i hasło2 ), a także ujawniło przybliżoną długość każdego z nich hasło.
Tryb szyfrowania EBC ma również inne słabości, takie jak fakt, że jest on wysoce plastyczny : jak każdy blok tekstu jawnego jest szyfrowany osobno, osoba atakująca może łatwo wygenerować nowe prawidłowe szyfrogramy, łącząc bloki z wcześniej zaobserwowanych tekstów szyfrowania.
Jednak plastyczność jest problemem tylko wtedy, gdy szyfrowanie EBC jest używane bez kod uwierzytelniania wiadomości iw tej sytuacji jest współdzielony (do pewnego stopnia) przez wszystkie inne nieuwierzytelnione tryby szyfrowania , podobnie jak wspomniane wyżej CBC, CTR, CFB i OFB. W związku z tym nie można go uważać za specyficzną słabość trybu EBC, nawet jeśli jest to dodatkowy problem, gdy kiedykolwiek używany jest tryb EBC.
Czego powinienem używać zamiast tego?
Należy używać dowolnego uwierzytelnionego szyfrowania tryb, na przykład GCM , EAX lub OCB .
Osobiście, w przypadku krótkich wiadomości, raczej lubię tryb SIV ( RFC 5279 ), co zapewnia dodatkową warstwę odporności na nadużycia. (Wiele innych trybów szyfrowania raczej źle się zepsuje, jeśli ten sam IV / nonce zostanie przypadkowo użyty do zaszyfrowania wielu wiadomości. Tryb SIV zachowuje wszystkie swoje właściwości bezpieczeństwa w tej sytuacji, z wyjątkiem wycieku, czy zaszyfrowane wiadomości są identyczne.)
Możesz także użyć dowolnego tradycyjnego semantycznie bezpiecznego trybu szyfrowania (takiego jak CBC lub CTR ), w połączeniu z kodem uwierzytelniającym wiadomości (takim jak HMAC ) za pomocą Encrypt -później-MAC . (Oznacza to, że powinieneś najpierw zaszyfrować wiadomość, a następnie obliczyć MAC zaszyfrowanego tekstu i dołączyć go do zaszyfrowanego tekstu.) Tak długo, jak upewnisz się, że zweryfikujesz MAC przed próbą odszyfrowania wiadomości, ta konstrukcja ochroni cię przed różne podatności tych trybów na ataki aktywne (z wybranym zaszyfrowanym tekstem).
W przypadku szyfrowania dysku lub podobnych aplikacji, które wymagają możliwości modyfikowania części szyfrogramu bez ponownego szyfrowania wszystkich danych, należy użyć trybu szyfrowania przeznaczonego do tego celu, takiego jak XTS . Należy pamiętać, że takie tryby generalnie nie są odporne na aktywne ataki i mogą mieć inne słabości, które należy zrozumieć przed ich użyciem. Jeśli to możliwe, należy je połączyć z jakąś formą ochrony integralności, taką jak MAC na drzewie skrótów .
Komentarze
- Co byś zasugerował w przypadkach, gdy ktoś chciałby mieć możliwość odczytu / zapisu bloków magazynu danych w dowolnej kolejności, najlepiej podczas tworzenia mapy bloków typu all-one blokują? Chciałbym zaszyfrować przez xorowanie danych bloku za pomocą bardzo prostego skrótu numeru bloku, cofnięcie / powtórzenie operacji xor, jeśli daje ona blok all-one, użycie EBC na wyniku i xorowanie z uzupełnieniem wyniku szyfrowania bloku typu all-one [to uzupełnienie musi być obliczone tylko raz dla każdego klucza]. Czy to byłoby dobre podejście?
- @supercat: To ' jest w zasadzie szyfrowaniem dysku , więc możesz użyć trybów zaprojektowanych do tego. Uważam, że XTS jest uważany za dobry wybór, chociaż, podobnie jak wszystkie tryby szyfrowania dysku, ma swoje ograniczenia (które należy zrozumieć przed użyciem). Jeśli to możliwe, powinno być połączone z jakimś MAC, aby chronić się przed aktywnymi atakami.
- @IlmariKaronen: myślę, że mówiąc " don ' t użyj ECB " to trochę przesada. Rozumiem ryzyko, ale wiele razy (chyba że Twój dokument – to, co szyfrujesz – nie jest ' t bardzo tajny, a przeciwnik nie ' nie masz zbyt wielu możliwości itp.), powinno być dobrze.
- @giorgim: ' naprawdę nie ma dobrego powodu używać EBC (z wyjątkiem jako elementu konstrukcyjnego dla innych trybów). Prawie każda biblioteka kryptograficzna zapewnia przynajmniej tryb CBC lub CTR, a jeśli nie, to ' są trywialne do samodzielnego wdrożenia. Dodaj do tego HMAC (lub CMAC), a ' jesteś gotowy.
- @giorgim: Nawet jeśli nie ' nie ma żadnego trybu MAC lub AE, używanie CBC jest nadal zdecydowanie lepsze niż ECB. Jeśli masz funkcję MAC, CBC-then-MAC jest doskonałym trybem AE.
Odpowiedź
Nie należy używać trybu ECB, ponieważ będzie on szyfrował identyczne bloki wiadomości (tj. Ilość danych zaszyfrowanych przy każdym wywołaniu szyfru blokowego) do identycznych bloków szyfrogramu. Jest to problem, ponieważ ujawni, czy te same bloki wiadomości są szyfrowane wiele razy. Wikipedia bardzo ładnie ilustruje ten problem .
Komentarze
- Komentarze nie nadają się do dłuższej dyskusji; ta rozmowa została przeniesiona do czatu .
Odpowiedź
Jak wspomniał @Guut Boy, EBC nie jest zabezpieczony semantycznie w tym sensie, że jeśli wiadomość z identycznymi blokami jest zaszyfrowana, atakujący uzyskuje pewną przewagę, mając informacje w postaci zwykłego tekstu, obserwując jedynie tekst szyfrowany.
Do szyfrowania długich wiadomości najlepiej używać trybu CBC. Ten tryb wprowadza dodatkowy parametr o nazwie IV (Wartość początkowa), inicjuje się numerem sesji, aby zapobiec atakom w przypadku dwukrotnego zaszyfrowania tej samej wiadomości.
Komentarze
- IV oznacza wektor inicjujący, a nie wartość początkową.
- 1. To nie jest dobra rada. Używanie szyfrowania bez uwierzytelnianie ignoruje około dziesięciu lat rad kryptografów. Lepiej byłoby użyć uwierzytelnionego szyfrowania, zgodnie z zaleceniami Ilmari Karonena. 2. Ta odpowiedź wydaje się być zastąpiona przez Ilmari Karonen ' s odpowiedź.
- Poza tym faktem jest, że IV musi być nieprzewidywalny dla atakującego (tj. nie do odróżnienia od losowego), a ta odpowiedź mówi, że powinieneś użyć numeru sesji, który zwykle wcale nie jest losowy.
Dodaj komentarz