Szyfrowanie AES 16 bajtów bez użycia soli

Question

Jak bezpieczne jest szyfrowanie 16 bajtów danych w jednym bloku z AES? Bez soli/IV, bez trybu działania, zaszyfrowane miliony różnych 16-bajtowych bloków. Nie wiem wystarczająco dużo o krypto, ale to mi pachnie.

Edytuj: aby podać nieco więcej szczegółów, nie chodzi o szyfrowanie wiadomości, ale o kolumnę tabeli bazy danych, w której długość zwykłego tekstu wynosi 16 bajtów. Dane nie są całkowicie losowe (pierwsze 8 bajtów będzie często takie same) i istnieje suma kontrolna, która identyfikuje pomyślne odszyfrowanie.

Wchodzę na spotkanie z chłopakami proponującymi to w przyszłym tygodniu, a jeśli pojawi się problem, bardzo docenię niektóre wskazówki do materiałów referencyjnych, dzięki którym mogę pokazać, że projekt jest niepewny. Nie jestem w pełni zaznajomiony z systemem, ale myślę, że może to wymagać poważnego przeprojektowania, aby obejść się, więc prawdopodobnie istnieje duży opór. Większość zaangażowanych osób (i siła) znajduje się po stronie biznesowej, gdzie motywacją jest uzyskanie działającego systemu ...

Answer 1

EBC nie jest bezpieczny do użytku ogólnego. Dany zwykły tekst zawsze szyfruje do tego samego tekstu szyfrowania, dzięki czemu można ujawnić wzorce. Istnieją jednak specjalne przypadki, w których jest to bezpieczne, a ta aplikacja może być jednym z nich.

Cytowanie Kryptografia stosowana, wydanie drugie str. 190 w odniesieniu do trybu EBC dla szyfru blokowego:

na plus, nie ma bezpieczeństwa ryzyka szyfrowanie wielu wiadomości z tym samym kluczem. W rzeczywistości każdy blok może być postrzegany jako osobny komunikat zaszyfrowany tym samym kluczem.

Później (str. 208), Schneier mówi:

Jeśli prostota i szybkość są twoje główne obawy, EBC jest najprostszym i najszybszym trybie użyć szyfru blokowego. To najsłabiej jest też .Oprócz tego, że jest on podatny na ataki typu "powtórka", algorytm w trybie ECB jest najłatwiejszy do przetestowania pod kątem kryptoanalizy niż . Nie polecam ECB dla szyfrowania wiadomości.

Do szyfrowania danych losowych, takich jak innych kluczy, EBC jest dobrym trybem do użycia. Ponieważ dane są krótkie i losowe, żaden z niedociągnięć sprawy EBC dla tego wniosku.

Wspólny prefiks i cyfra kontrolna w twoim przypadku nie będą generować wspólnego tekstu zaszyfrowanego. Dzieje się tak tylko wtedy, gdy zduplikowany zostanie cały blok tekstu jawnego w postaci . Z tego co opisałeś, twoja aplikacja może być odpowiednia dla ECB —, zwłaszcza, jeśli każda wartość zwykłego tekstu, jako całość, jest unikalna.

Answer 2

Bez soli, znanej również jako wektor inicjujący lub IV, bezpieczeństwo cyphertekstu (i, jak sądzę, klucz również) jest znacznie zredukowany. Potencjalny napastnik znacznie łatwiej będzie rozpoznać powtarzające się wzorce w zaszyfrowanym tekście. IIRC to był ten sam podstawowy błąd, który Microsoft popełnił przy aktualizacji schematu szyfrowania MS Office.

Answer 3

W warunkach kryptografii jest to niebezpieczne tylko wtedy, gdy atakujący zna konkretny algorytm i IV.

Założono pewne przypuszczenie: Po odszyfrowaniu, czy atakujący wie, jak wyglądają dane, aby wiedzieć, że próba odszyfrowania zakończyła się powodzeniem? na przykład Czy istnieje MD5, CRC lub jakaś forma sumy kontrolnej, która może zweryfikować pomyślną deszyfrację? Jeśli tak, dajesz osobie atakującej sposób na potwierdzenie tej próby.

Ale jeśli chodzi o hakowanie, wciąż jest 2^128 kombinacji kluczy (dla szyfrów 128-bitowych), co jest tak samo bezpieczne, jak używanie tego samego klucza na terabajtach danych. Tryb działania jest nieistotny, ponieważ 16 bajtów danych to tylko jeden blok, więc nie stosuje się szyfrowania blokowego szyfrowania (CBC).

Jednak sól IV ma zastosowanie i ta wartość powinna być tak samo sekretna jak sam klucz. Tęczowy stół może być użyty do przyspieszenia ataku brute force na szyfry bez użycia soli; to jest twój słaby link.

Answer 4

AES jest dość silny przeciwko atakom tylko zaszyfrowanym tekstem. Jednak szyfrowanie wielu tekstów jawnych za pomocą tego samego klucza sprawia, że ​​system jest bardziej podatny na ataki znanego-jawnego tekstu i ataków na zwykły tekst.

W związku z tym, jeśli klucz szyfrowania jest losowy, a tekst jawny jest pozornie losowy, nadal możesz być bezpieczny. Ale zdecydowanie chciałbym użyć różnych kluczy.

Z drugiej strony, jeśli zwykłe teksty są ze sobą powiązane i/lub pozornie przypadkowe, EBC nie jest w ogóle bezpieczny.

Answer 5

Nie znam żadnych słabych punktów AES w przypadku krótkich wiadomości. Algorytm powinien być bardzo szczęśliwy.

Aby wziąć na spotkanie ty chcesz.

1) Model zagrożenie (którzy mogą zobaczyć, co, kiedy i co się dzieje, gdy opuszczają lub stać się „złego faceta)

2) Niektóre przypadki użycia z Twojego modelu zagrożenia:

Dzięki temu powinieneś być w stanie określić, czy naprawdę potrzebujesz soli AES i czy szyfrowanie naprawdę chroni wartość w kolumnie, jeśli możesz ją wyprowadzić gdzie indziej, korzystając z AES Na koniec zadaj pytanie: "Czy klucz jest naprawdę bezpieczniejszy niż dane?" Widziałem takie programy, w których klucz był tego samego rozmiaru co t on dane (gdzie size = "kinda small") i był tak samo dostępny, jak dane, które chronił. Tak, kupi ci to kilka godzin, podczas gdy atakujący odkryje, co u licha zrobiłeś, ale to nie daje ci dużo w kwestii solidnego bezpieczeństwa.

Mam nadzieję, że pomaga i daje ci coś do żucia. Nie znając konkretnej pozycji, trudno jest dopasować odpowiedź. :)