Bezpieczne szyfrowanie pliku
Powszechnie znana jest metoda szyfrowanie plików za pomocą xor-owania(różnicy symetrycznej) jego zawartości. Metoda ta jest jednak stosunkowo łatwa do złamania, gdy wiemy, czego możemy spodziewać się po rozszyfrowanej treści. Metoda, którą chciałbym przedstawić także polega na XOR-owaniu zawartości pliku, tylko, że mamy tu doczynienia z kluczem nie 5, czy 10 znakowym, leczo długości porównywalnej z rozmiarem pliku. Jak łatwo się domyślić taki klucz musi być zapisany ( najlepiej to zrobić na dyskietce/płycie CD-R ) na stałym nośniku. Klucz taki to przypadkowa kombinacja liczb losowych. Dokładniej rzecz biorąc są to liczby tzw. pseudolosowe, generowanie liczb losowych przekracza bowiem możliwości naszych biednych PC'tów. W NSA do generowania tychże kluczy (tzw. kluczy jednorazowych) używa się kilkunastu anten radiowych, które wyłapują zakłócenia z atmosfery, które następnie "przepuszczane" są przez komputer, który przetwarza losowe zmiany napięcia na liczby. Teoretycznie dane zaszyfrowane kluczem jednorazowym są nie do złamania, nawet na CRAYACH X (czy jak im tam), oczywiście przy zastosowaniu odpowiedniego algorytmu szyfrującego. Danych zakodowanych kluczem jednorazowym nie da się złamać na postawie analizy występowania znaków, ani nawet przez próbowanie po kolei wszystkich kluczy ( a dla tekstu 10 literowego jest to 255(tyle jest znaków ASCII)*10^10). Przykład? Proszę:
Mamy tekst jawny: "4programmers.net" szyfrujemy go przy użyciu hasła: "123456789012345", czyli XOR-ujemy ze sobą pierwszy znak tekstu (a dokładniej jego kod ASCII) i pierwszy znak hasła, aż do n-tego znaku tekstu i hasła.(Odszyfrowywanie polega na zrobieniu tego samego z zaszyfrowanym tekstem, czyli w odwrotnej kolejności) Tak otrzymany "tekst" zaszyfrowany ktoś usiłuje rozszyfrować poprzez podstawianie kolejno wszystkich możliwych kluczy. POWODZENIA, dlaczego??? Odszyfrowanie naszego zaszyfrowanego tekstu przez podanie kolejnych kluczy spowoduje powstanie wielu sensownych ciągów!!! Np. odszyfrowanie naszego tekstu przez podstawienie hasła >>f-a6+d" t8",dzoK<< da w rezultacie tekst, "co my tu mamy??" który jest jak najbardziej poprawny, ale przecież to nie o ten tekst chodziło.
Po tej dawce "teorii" można przejść do "praktyki".
Pod tym adresem znajduja się przykłady generatora i szyfratora.
Życzę miłego szyfrowania.
Chyba cos przeoczyłeś w swojej propozycji.
Twój genialny sposób przerzuca ciężar odpowiedzialności ze strzeżenia n kilobajtów danych na strzeżenie n kilobajtów klucza.
A opis wskazuje, że chciałbyś tego klucza użyć jeszcze parę razy.
No i tu jest problem. "One time pad" jest rzeczywiście najlepszy, ale głównie w teorii.
Trzeba rozwiązać problem dystrybucji kluczy (dystrybucji, przechowywania, bezpiecznego odczytu, dodałbym pracochłonnego przetwarzania, i na koniec absolutnie pewnego niszczenia wykorzystanego klucza).
A druga część to to że MUSI być wykorzystany tylko raz.
O tym co będzie w przeciwnym razie poszukaj sobie pod hasłem VENONA.
Qyon ma rację a Przemek się myli (źle zrozumiał panią Denning, albo Dorothy E. Denning powinna zmienić zawód ;-) Wyjaśnię to na przykładzie: bierzemy dowolny plik o długości (n) bajtow i szyfrujemy go polecanym przez Przemka algorytmem AES (tryb ECB czy CBC jest nieistotny, podobnie jak klucz), w wyniku działania algorytmu otrzymamy zaszyfrowany plik o długości (n) bajtów. Ponieważ oba pliki mają tą samą długość, wiec istnieje dokładnie jeden ciąg znaków (również mający długość (n)), który po XOR-owaniu go z plikiem wejściowym da nam plik identyczny z tym otrzymanym za pomocą AES. (że taki ciąg istnieje można się przekonać wykonując operację: plik wejściowy XOR plik po AES :-))))) Jedyną słabością rozwiązania zaproponowanego przez Qyona, jest fakt, ze implementacja funkcji Randomize zastosowana przez firmę Borland, jest niezła w wiekszości zastosowań, ale niestety w kryptografii, pseudolosowe ciągi uzyskane w wyniku jej działania dają się "złamać" bez wiekszego problemu.
B.G.
Czy próbowałeś kiedyś xor-ować literę zaszyfrowaną i niezaszyfrowaną ?
Poczytaj trochę Denning, to zobaczysz, że ten system nie jest najlepszy.
Polecam Ci RSA, lub AES
Przemek