4.3 Wyniki badań

W tej części pracy zostaną pokazane różne wykresy statystyczne kryptogramów powstałych, podczas analizy algorytmu szyfrującego opisanego w rozdziale 3.

Poniższe wykresy pokazują charakterystyki kryptogramów powstałych z dwóch typów plików tekstowego i archiwum typu .RAR. Wynika to z tego iż charakterystyki innych plików powielały się, zatem nie będą brane pod uwagę w dalszych rozważaniach.

Kryptogram z pliku tekstowego, jeden klucz dla każdego bloku danych:

Kryptogram z pliku tekstowego, klucz losowy dla każdego bloku danych:

Kryptogram z pliku tekstowego, z łączeniem bloków danych:

Jak widzimy powyższe wykresy na razie nie wskazują na to aby omawiany szyfr blokowy był lepszy od innych bardziej znanych. Wynika to z tego ze plik tekstowy tworzy się korzystając z niepełnego kodu ASCII. Poza tym kryptogramy utworzone z plików tekstowych przez algorytmy konkurencyjne nie posiadają lepszych charakterystyk. Jako przykład wskaże algorytm IDEA:

Jednym ze sposobów na polepszenie charakterystyk kryptogramu tworzonego z pliku tekstowego jest wcześniejsza kompresja pliku tekstowego.

Skompresowany plik tekstowy, jeden klucz dla wszystkich bloków danych:

Skompresowany plik tekstowy, klucz losowy dla każdego bloku danych:

Skompresowany plik tekstowy, ze sprzężeniem bloków kryptogramu:

Znaczącą poprawe widzimy jedynie dla kryptogramu tworzonego w trybie: jednakowego klucza dla każdego bloku danych. Pozostałe wykresy będą podobne. Jednak na tle innych algorytmów wynik wydaje się satysfakcjonujacy. Dla porównania kryptogram utworzony przez algorytm IDEA, ze skompresowanego pliku tekstowego ma gorszą chrakterystykę niż przed kompresją pliku tejkstowego:

Następne wykresy będą wynikiem analizy średniej i dużej wielkości plików typu .RAR. Na początek średniej wielkości plik (ok. 40.Mb), jeden klucz dla każdego bloku danych:

Średniej wielkości plik , klucz losowy dla każdego bloku danych:

Średniej wielkości plik , ze sprzężeniem bloków kryptogramu:

Dużej wielkości plik (ok. 900 Mb), jeden klucz dla każdego bloku danych:

Dużej wielkości plik (ok. 900 Mb), klucz losowy dla każdego bloku danych:

Dużej wielkości plik (ok. 900 Mb) , ze sprzężeniem bloków kryptogramu:

W tym momencie uwidoczniła się duża zaleta omawianego szyfru blokowego, dla plików o wielkości kilkunastu - megabajtów lub większych kryptogramy w znacznym stopniu zbliżyły się do wcześniej pokazanego ideału. Można tu stwierdzić iż opisywany algorytm idealnie nadaje się do szyfrowania klikunastomegowych lub większych plików. Dodatkowym atutem naszego szyfru jest korygowanie modyfikacji kryptogramu. Dla przykładu:

Przykładowa wiadomość:

Kryptogram wygląda następująco:

Osoba niepowołana modyfikuje kryptogram w następujący sposób:

zmieniając numer konta.

Porównanie obu kryptogramów:

Zmodyfikowany: Oryginalny:

Różnicę zaznaczono na czerwono, po deszyfrowaniu algorytm poprawia błędy i otrzymana wiadomość wygląda następująco:

numer konta został poprawiony.

Oczywiście algorytm nie jest idealny, nie poprawia wszystkich błędów. Wynika to z możliwości korekcyjnych cyklicznego kodu Reeda - Solomona. W naszym przypadku na każde 125 bajtów danych przypada 131 bajtów korekcyjnych. Zatem ze wzoru
obliczamy możliwość korekcyjną kodu, gdzie d oznacza ilość bajtów korekcyjnych. Zatem t = 65. Kod koryguje 65 błędów zgrupowanych na długości 131 bajtów.

Jednak gdy błędy będą wystąpią na większej długości niż długość bajtów korekcji, algorytm nie skoryguje zaszumionego bloku danych:

Przykładowa wiadomość:

Kryptogram wygląda następująco:

Odebrany kryptogram zawiera dość dużo błedów:

jest bardzo nie czytelny.

Porównanie obu kryptogramów:

Zmodyfikowany: Oryginalny:

Różnicę zaznaczono na czerwono, po deszyfrowaniu algorytm nie poprawia błędów i otrzymana wiadomość wygląda dość nie czytelnie:

Jak widzimy algorytm jest wrażliwy na celowe modyfikacje kryptogramu a nie przypadkowe. Jednak w dobie dużego rozwoju komunikacji, kanały telekomunikacyjne mają dużą zdolność korygowania tych przypadkowych błędów. Zatem nasuwa się konkluzja, iż opisywany szyfr blokowy jest bardzo dobrym narzędziem od ochrony danych.

Proszę wpłacić do dnia 14.02.2003 na konto: 11111111-111111111, sumę: 1000 zł, jako ratę kredytu, na nazwisko Jan Kowalski.

Proszę wpłacić do dnia 14.02.2003 na konto: 22222222-222222222, sumę: 1000 zł, jako ratę kredytu, na nazwisko Jan Kowalski.

Proszę wpłacić do dnia 14.02.2003 na konto: 11111111-111111111, sumę: 1000 zł, jako ratę kredytu, na nazwisko Jan Kowalski.

Proszę wpłacić do dnia 14.02.2003 na konto: 11111111-111111111, sumę: 1000 zł, jako ratę kredytu, na nazwisko Jan Kowalski.

PÜosŤe wpłacić db dniž 14.02 2003 ÓaŻkonto:Ig11L111-11ŕÁ†1ô1,©suÉęZ 1000 zł, jko ratE kredytľz na±nazµisk Jan Kcwolski.

PÜosŤe wpłacić db dniž 14.02 2003 ÓaŻkonto:Ig11L111-11ŕÁ†1ô1,©suÉęZ 1000 zł, jko ratE kredytľz na±nazµisk Jan Kcwolski.

---