osobliwy nick
2019-11-05 18:44:51 UTC
Zastanawiam się nad pewnym schematem algorytmu szyfrującego. Nie spotkałem tego rodzaju schematu w żadnych stosowanych algorytmach, co mnie trochę dziwi, bo nie jest to trudna idea.
Pomysł jest następujący. Załóżmy, że mamy jakąś funkcję szyfrującą. I szyfrujemy wiadomości w blokach powiedzmy 20-bitowych. Ale dokonujemy pewnej operacji - podmieniamy połowę bitów na kompletnie losowe. Tym samym na realną wiadomość mamy do dyspozycji tylko 10 bitów. Zaletą jest to, że zmienia to kompletnie wynik końcowy szyfrowania, połowa bitów już na wstępie jest losowa. Zaś ta, która zostaje, jest jeszcze dodatkowo szyfrowana, razem z losową połową.
Jak tego dokonać? Otóż musimy posłużyć się w tym celu jakąś funkcją porządkowo - hashującą. To co robimy, to hashujemy wartości 1, 2, 3, ..., n (tworzymy tyle bloków ile trzeba, aby zmieścić wiadomość). W wyniku dostajemy kolejne 20-bitowe bloki. Hashowanie musi być unikalne, to znaczy - musi to być funckja hasjująca ze zmiennym kluczem, których musi być wiele. Chodzi o to, żeby atakujący nie był w stanie stwierdzić jak zahashowano np. liczbę jeden i jaki dokładnie blok 20-bitowy ta liczba daje (musi mieć do tego klucz). Myślę, że bardzo łatwo stworzyć taką funkcję - wystarczy chociażby posłużyć się zwykłą funkcją szyfrującą i dodać jakieś operacje XOR w kolejnych rundach (albo jakoś wymieszać proces szyfrowania), tak, żeby nie dało się jej już odszyfrować jak dotychczas, według kluczy (ja mam taką funkcję). Ważne jest to, aby średnio funkcja taka dawała dla każdej liczby 1, 2, 3,... połowę bitów w postaci 1 i połowę w postaci 0. Wówczas możemy ustalić, że powiedzmy zawsze podstawiamy w miejsca 0 losowe bity. Zaś w miejsca 1 wstawiamy bity naszej wiadomości. Następnie szyfrujemy całość we właściwej funkcji szyfrującej.
Odbiorca, który chce odszyfrować wiadomość oblicza sobie kolejno bloki zaczynając od 1, czyli po prostu hashuje liczbę 1 i dzięki temu wie które bity już pod odszyfrowaniu to wiadomość, a które pominąć, bo są losowe. Tak jak pisałem, zmienia to kompletnie wynik szyfrowania. Bez znajomości porządkowej funkcji hashującej i konkretnego klucza hashującego odtworzenie zaszyfrowanej wiadomości jest praktycznie niemożliwe, bo oryginalne bity wiadomości mogą być nie tyko w różnych miejscach 20-bitowego bloku, ale są też wymieszane z losowymi bitami. Z kolei uzyskanie kluczy funkcji hasjującej, pomimo, że dla każdej sesji hashujemy te same liczby 1, 2, 3,... również jest trudne, bo zahashowane wyniki są następnie wypełniane w połowie wiadomością, a połowie losowym ciągiem i później jeszcze szyfrowane.
W szczególności strony mogą ustalić jakąś unikalną, losową permutację liczb od 1 do n, najlepiej równą średniej planowanej liczbie bloków, która będzie przesyłana w trakcie sesji. Załóżmy, że najczęściej strony przesyłają między sobą 100 bloków. Wówczas permutacja powinna liczyć 100 liczb. I każdy blok w danej sesji powinien być szyfrowany poczynając od wyznaczenia 20-bitowego bloku dla pierwszej liczby z tej permutacji. W szczególności permutację można zmieniać w ramach każdej sesji, bez konieczności zmiany kluczy albo ustalić tak długą permutację, że przez lata nie zostanie ona zrealizowana. Jeśli strony zakończyły szyfrowanie na np. 100 elemencie permutacji, to kolejną sesję zaczynają od elementu 101. Każda wiadomość będzie wówczas szyfrowana w sposób unikalny, pomimo, że tymi samymi kluczami.
Wydaje mi się to prosta idea, choć opis zajmuje trochę miejsca. Chodzi po prostu o funkcję hashująco-porządkową poprzedzającą szyfrowanie każdego bloku i mówiącą jak ten blok zaszyfrować. Dlaczego nikt takiego pomysłu jak dotychczas nie zrealizował? A jedynym zastosowaniem mieszania wiadomości z losowym ciągiem bitów, który znam jest dodawanie soli do haseł, które są hashowane. Dlaczego nie dodawać soli do szyfrowanych wiadomości?
Pomysł jest następujący. Załóżmy, że mamy jakąś funkcję szyfrującą. I szyfrujemy wiadomości w blokach powiedzmy 20-bitowych. Ale dokonujemy pewnej operacji - podmieniamy połowę bitów na kompletnie losowe. Tym samym na realną wiadomość mamy do dyspozycji tylko 10 bitów. Zaletą jest to, że zmienia to kompletnie wynik końcowy szyfrowania, połowa bitów już na wstępie jest losowa. Zaś ta, która zostaje, jest jeszcze dodatkowo szyfrowana, razem z losową połową.
Jak tego dokonać? Otóż musimy posłużyć się w tym celu jakąś funkcją porządkowo - hashującą. To co robimy, to hashujemy wartości 1, 2, 3, ..., n (tworzymy tyle bloków ile trzeba, aby zmieścić wiadomość). W wyniku dostajemy kolejne 20-bitowe bloki. Hashowanie musi być unikalne, to znaczy - musi to być funckja hasjująca ze zmiennym kluczem, których musi być wiele. Chodzi o to, żeby atakujący nie był w stanie stwierdzić jak zahashowano np. liczbę jeden i jaki dokładnie blok 20-bitowy ta liczba daje (musi mieć do tego klucz). Myślę, że bardzo łatwo stworzyć taką funkcję - wystarczy chociażby posłużyć się zwykłą funkcją szyfrującą i dodać jakieś operacje XOR w kolejnych rundach (albo jakoś wymieszać proces szyfrowania), tak, żeby nie dało się jej już odszyfrować jak dotychczas, według kluczy (ja mam taką funkcję). Ważne jest to, aby średnio funkcja taka dawała dla każdej liczby 1, 2, 3,... połowę bitów w postaci 1 i połowę w postaci 0. Wówczas możemy ustalić, że powiedzmy zawsze podstawiamy w miejsca 0 losowe bity. Zaś w miejsca 1 wstawiamy bity naszej wiadomości. Następnie szyfrujemy całość we właściwej funkcji szyfrującej.
Odbiorca, który chce odszyfrować wiadomość oblicza sobie kolejno bloki zaczynając od 1, czyli po prostu hashuje liczbę 1 i dzięki temu wie które bity już pod odszyfrowaniu to wiadomość, a które pominąć, bo są losowe. Tak jak pisałem, zmienia to kompletnie wynik szyfrowania. Bez znajomości porządkowej funkcji hashującej i konkretnego klucza hashującego odtworzenie zaszyfrowanej wiadomości jest praktycznie niemożliwe, bo oryginalne bity wiadomości mogą być nie tyko w różnych miejscach 20-bitowego bloku, ale są też wymieszane z losowymi bitami. Z kolei uzyskanie kluczy funkcji hasjującej, pomimo, że dla każdej sesji hashujemy te same liczby 1, 2, 3,... również jest trudne, bo zahashowane wyniki są następnie wypełniane w połowie wiadomością, a połowie losowym ciągiem i później jeszcze szyfrowane.
W szczególności strony mogą ustalić jakąś unikalną, losową permutację liczb od 1 do n, najlepiej równą średniej planowanej liczbie bloków, która będzie przesyłana w trakcie sesji. Załóżmy, że najczęściej strony przesyłają między sobą 100 bloków. Wówczas permutacja powinna liczyć 100 liczb. I każdy blok w danej sesji powinien być szyfrowany poczynając od wyznaczenia 20-bitowego bloku dla pierwszej liczby z tej permutacji. W szczególności permutację można zmieniać w ramach każdej sesji, bez konieczności zmiany kluczy albo ustalić tak długą permutację, że przez lata nie zostanie ona zrealizowana. Jeśli strony zakończyły szyfrowanie na np. 100 elemencie permutacji, to kolejną sesję zaczynają od elementu 101. Każda wiadomość będzie wówczas szyfrowana w sposób unikalny, pomimo, że tymi samymi kluczami.
Wydaje mi się to prosta idea, choć opis zajmuje trochę miejsca. Chodzi po prostu o funkcję hashująco-porządkową poprzedzającą szyfrowanie każdego bloku i mówiącą jak ten blok zaszyfrować. Dlaczego nikt takiego pomysłu jak dotychczas nie zrealizował? A jedynym zastosowaniem mieszania wiadomości z losowym ciągiem bitów, który znam jest dodawanie soli do haseł, które są hashowane. Dlaczego nie dodawać soli do szyfrowanych wiadomości?