Jak symetrycznie zaszyfrować wartości 64-bitowe?

Ciekawi mnie algorytm, który byłby dobry w następującym scenariuszu:

  1. 32-bitowy „zwykły tekst” wejście, pobrane z licznika
  2. 32- lub 64-bitowe wyjście „zaszyfrowanego tekstu”
  3. Powinno być możliwe odszyfrowanie danych wyjściowych za pomocą klucza (i ewentualnie kilku innych ukrytych parametrów, takich jak offset i bieżący licznik) i zwraca oryginalną 32-bitową wartość licznika
  4. Użytkownik nigdy nie obserwuje danych wejściowych, ale może otrzymać dowolną liczbę wyjść, prawdopodobnie sekwencyjnych. Mimo to nie powinni być w stanie wiedzieć, jakie mają indeksy.
  5. Powinno być trudno odgadnąć inne wyniki, które odpowiadają prawidłowym wartościom liczników.

Moja niewytrenowana intuicja jest taka, że skoro klucz i wyjścia są większy niż przestrzeń wejściowa, powinno być dość łatwo uzyskać „dobre” wyniki, przynajmniej dla kilku pierwszych wyników. Jednak wydaje się logiczne, że przy wystarczającej liczbie próbek klucz i indeksy można łatwo obliczyć, ale oczekuję, że większość przypadków używać l es niż 100 wartości.

Moje pytania to:

  1. Czy istnieją jakieś algorytmy, które działają w tym scenariuszu?
  2. Jak trudne byłoby pęknięcie? To znaczy oblicz wartości, które odszyfrowują do prawidłowych wskaźników.
  3. W jakim stopniu posiadanie większej liczby próbek wpływa na skuteczność ich łamania?
  4. Co jest złego w naiwnym podejściu na przykład:

    u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37 

    Zakładając, że dodawanie obejmuje 64-bitowe granice liczb całkowitych. Wygląda na to, że całkowicie wymieszałby losowy klucz z jednym wejściem, ale posiadał więcej niż jeden dane wyjściowe mogą szybko zwiększyć ilość informacji posiadanych przez atakującego, chociaż nie wiedziałbym jak. Oczywiście to się zepsuje, próbuję się tylko nauczyć.

  5. Użyłbym wartości zależnej od klucza dla rotacji w lewo, na przykład (((key & 0xFFFE)+1) * 37) będzie lepiej? Ile to pomaga i dlaczego?
  6. Jakich podejść, zasobów itp. Użyłbyś do analizy algorytmu i zaprojektowania lepszego?

Komentarze

  • To jest bardzo problem XY w sposobie, w jaki go opisujesz. CSPRNG (zwróć uwagę na S) w ogóle nie wydaje się być dobrym rozwiązaniem w tym przypadku '. Żądanie rozmiaru klucza jest trochę dziwne, dlaczego nie można użyć większych rozmiarów klucza?
  • Przypuszczam, że rozmiar klucza nie jest niezbędny. Miałem nadzieję, że 64-bitowy klucz wystarczy do zaszyfrowania wartości 32-bitowej.

Odpowiedź

  1. Czy istnieją jakieś istniejące algorytmy, które działają w tym scenariuszu?

Tak, właściwie , istnieje wiele 64-bitowych szyfrów blokowych. Standardowa mądrość jest taka, że nie są one zachęcane do ogólnego użytku, ponieważ standardowe tryby szyfrowania blokowego zwykle zaczynają wyciekać informacje, gdy zbliżasz się do daty urodzin (w tym przypadku około 30 GB); jednak w twoim przypadku bądź problemem.

Oto kilka opcji:

  • 3DES (aka TDES); jest to DES zastosowany trzy razy z trzema różnymi klawiszami; ma to tę zaletę bardzo dobrze przestudiowany.

  • Speck , który ma zestawy parametrów z 64-bitowymi szyframi blokowymi. zaletą bycia najszybszą alternatywą i został zaprojektowany przez ludzi, którzy wiedzą, że robią, i przeszli przez zaskakującą ilość kryptoanalizy.

  • Szyfr FPE (taki jak FF1, który może obsłużyć dowolny rozmiar bloku (w tym 64 bity). Ma to tę zaletę, że pozwala na zmianę (co jest wygodnym miejscem na umieszczenie „innych ukrytych parametrów”, jeśli zdecydujesz, że jest to zaleta) ). To jest wolniejszy niż alternatywy; w przypadku FF1 bezpieczeństwo pochodzi z podstawowego bezpieczeństwa AES, plus udowodnione bezpieczeństwo struktury Feistela.

Teraz te klucze wymagają kluczy dłuższych niż 64 bity; powszechna opinia jest taka, że 64-bitowy klucz jest po prostu za krótki.

  1. Jak trudne byłoby złamanie? To znaczy oblicz wartości, które odszyfrowują do prawidłowych indeksów.

W przypadku każdego z powyższych jedyną praktyczną opcją, jaką mógłby mieć przeciwnik, byłoby przypadkowo odgadnij szyfrogramy i miej nadzieję, że natkniesz się na taki, który odszyfrowuje do prawidłowego indeksu.

  1. Ile kosztuje posiadanie więcej próbek wpłynie na skuteczność jego złamania?

W przypadku każdego z powyższych, posiadanie dużej ilości próbek nadal sprawi, że atak będzie niewykonalny.

  1. Co jest złego w naiwnym podejściu, takim jak …

Szyfry ARX (właściwie każdy szyfr, ale szczególnie ARX) są trudne do uzyskania. W szczególności szyfry ARX nie są zbyt dobre w zakłócaniu charakterystyk różnicowych i liniowych (co oznacza takie projekt musiałby być naprawdę dobrze przestudiowany, aby mieć pewność, że tak jest).

  1. Jakich podejść, zasobów itp. użyłbyś do analizy algorytmu i zaprojektowania lepszego?

Proponuję wybrać projekt, który został już przeanalizowany; trzy powyżej wymieniam.

Komentarze

  • Ja ' wolę np. Blowfish zamiast 3DES, jeśli następuje zmiana stosunkowo niewielkiego klucza. Bezpieczeństwo 3DES wątpić, nawet jeśli klucz został rozszerzony do 128 bitów (a raczej 112 bitów, oczywiście).
  • @MaartenBodewes: czy masz cytat kogoś, kto pokazuje, że 3DES z Czy nieznany klucz można odróżnić od losowej, parzystej permutacji?
  • Nie, oczywiście, że nie. Jednak ' d raczej nie muszę nawet rozumować, jeśli moje szyfrowanie ma ~ 80-bitowa lub ~ 112-bitowa siła po podaniu 128-bitowego lub 192-bitowego klucza (ja ' nie mam wątpliwości, że byłbyś w stanie to zrobić, ale hej, my to nie wszystkie ponczo). A rozmiar klucza wydaje się być problemem w pytaniu. Samo wyrzucenie bitów parzystości w takim przypadku jest marnotrawstwem.
  • Czy mógłbyś rozwinąć instrukcję " Teraz te klucze wymagają dłuższych niż 64 bity; powszechna opinia jest taka, że 64-bitowy klucz jest po prostu za krótki. "? Które algorytmy wymagają kluczy o jakiej długości, a klucze 64-bitowe nie są wystarczająco długie do czego, dokładnie?
  • @shader: klucze tylko 64-bitowe są podatne na ataki brutalnej siły podczas przeszukiwania dużych (dobrze finansowanych) przeciwników. Ponieważ generalnie dość łatwo jest używać nieco większych kluczy (np. 128-bitowych), które nie są ' t wrażliwe dla nikogo, generalnie wybieramy bezpieczniejszą opcję (nawet jeśli nie są od razu zaniepokojeni, że NSA będzie zainteresowana zaatakowaniem nas lub jeśli Amazon zdecyduje się poświęcić nam całą swoją chmurę…

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *