🚀 go-pugleaf

U�ytkownik "Zmorzy�ski" <zmoraa@box43.pl> napisa� w wiadomo�ci
news:9g3c20$qm6$1@news.tpi.pl...
>
> U�ytkownik "Pan Stefan" <michalm@poczta.fm> napisa� w wiadomo�ci
> news:9g2i84$qg1$1@news.tpi.pl...
> >  A wiesz, tez mialem to na mysli!
> >
> Hehe... bo jest najpopularniejsze!
>
>
I bardzo skuteczne o ile ta "pewna warto��" kt�r� si� XORuje jest
przypadkowa.

Przyjmijmy, �e a[0...n] to kolejne bity jawnych danych a k[0..m] to bity
klucza, kt�ry jest u�yty do kodowania.
Je�eli m >= n oraz klucz  nie jest jaki� prymitywny (np. same jedynki) to
dane zosta�y perfekcyjne zakodowane.
Je�eli m < n (a zwlaszcza je�li jest du�o mniejsze), to kodowanie jest do
kitu (i NSA b�skawicznie dowie si� ile gracz ma punkt�w
oraz �y�). XORowanie zakodowanych w ten spos�b danych nimi samymi (ale z
pewnym przesuni�cie� zale�nym od d�ugo�ci klucza)
pozwala wy�uska� warto�� klucza.

Trzeba zatem utworzy� funkcj� (typu generator liczb pseudo losowych o do��
dobrych parametrach rok�adu itp) i wygenerowa� ci�g bit�w
o d�ugo�ci r�wnej n.

Dla potrzeb gry mo�na spr�bowa� w ten spos�b:
Obliczy� shash'owac has�o tak aby otrzyma� warto�� typu unsigned int.
Zainicializowa� randomizer (srandom(seed)) t� warto�ci� a nast�pnie pobiera�
kolejne pseudolosowe warto�ci (random).
Ka�dy bajt danych XORowa� z kt�rym� z bajt�w wylosowanego klucza.

Moc algorytmu (przy za�o�eniu, �e warto�ci s� losowe) jest proporcjonalna do
d�ugo�ci klucza. U�yta funkcja srandom() przyjmuje jako parametr unsigned
integer - czyli 4 bajty. Czterobajtowy klucz wymaga 2^32 pr�b aby wybr�bowa�
wszystkie mo�liwe kombinacje.

Nie polecam pisania w�asnej funkcji pseudolosowej bo takie na ogol bywaja
wybitnie nie-losowe a standardow� funkcj� random() w C napisa� kto� kto ma
wi�ksze poj�cie o matematyce ni� ja.

Oczywi�cie nie ma jakiejkolwiek potrzeby aby w opisywanej strukturze zawarte
bylo haslo (nawet nie powinno go tam absolutnie by�).

Pozostaje jeszcze funkcja hashuj�ca has�o. W prostym przypadku, nie trzeba
nic z nim robi� tylko wzi�� dowolne cztery znaki i przekonwertowa� do
warto�ci typu unsigned int ale wtedy zmiana jednego bitu w ha�le powoduje
zmian� jednego lub nawet �adnego bitu w warto�ci hash'a (dobre funkcje
mieszaj�ce maj� to do siebie �e zmiana jednego bitu w danych wej�ciowych
powoduje zmian� 50% bit�w na wyj�ciu). Tak czy inaczej wypada hashowa� to
tak aby wszystkie bity has�a zosta�y wzi�te pod uwag�.

Dobry algorytm koduj�cy ma to do siebie, �e je�li kryptoanalityk ma dane
zakodowane oraz kompletny opis algorytmu to i tak najszybsz� metod�
odkodowania jest metoda brutalna, kt�ra polega na sprawdzaniu wszystkich
mo�liwych kluczy. Algorytm podany przeze mnie najprawdopodobniej taki
w�a�nie jest (o ile funkcja random() nie b�dzie zwraca�a bez przerwy np.
1,2,4,3,8,6,1,2,4,3,8,6,1,2,4.....) i tylko kr�tki klucz czyni go s�abym.

Niestety tutaj chcemy jeszcze zabezpieczy� sytuacj� gdy kryptoanalityk
(czyli zaawansowany gracz, kt�ry chce r�cznie poprawi� swoje wyniki) zna
has�o i dane zakodowane oraz pewne cz�ci danych jawnych. Dodajmy te�, �e
zna dok�adnie algorytm kodowania (to nam upro�ci nasze przemyslenia i nie
sko�czymy na prostym XORowaniu danych powtarzaj�cym si� has�em).

W takiej sytuacji jedyne co powstrzyma go przed zdekodowaniem danych to
utajnienie cz�ci algorytmu np. funkcji hashuj�cej lub dodatkowe kodowanie
ca�o�ci danych kluczem znanym tylko programowi (czyli kluczem zaszytym w
kodzie programu) lub po��czenie tych metod.

Powiedzmy, �e funkcja hashuj�ca bierze 8 bajt�w has�a i XORuje je z o�mioma
bajtami klucza zaszytego w programie.
Mamy wtedy 64-bitowy klucz. Nast�pnie po�ow� bit�w XORuje (ORuje lub ANDuje)
z drug� po�ow� i skraca wynik do 32 bit�w i troch�
miesza bity.


Pseudokod kodowania danych:

unsigned int hash(char haslo[8])
{
  char tajnyklucz[] = { 1, 2, 3, 4, 5, 6, 7, 8 };

 for (int i = 0; i < 8; i++)
     tajnyklucz[i] ^= haslo[8];

unsigned int rezultat = 0;

rezultat |= (tajnyklucz[0] ^ tajnyklucz[1]) ;
rezultat <<= 8;
rezultat |= (tajnyklucz[2] ^ tajnyklucz[3]) ;
rezultat <<=8;
rezultat |= (tajnyklucz[4] ^ tajnyklucz[5]);
rezultat <<=8;
rezultat |= (tajnyklucz[6] ^ tajnyklucz[6])

return rezultat;
}

void kodowanie_i_dekodowanie(char * dane_we; char* dane_wy, int
rozmiar_danych char has�o[8])
{
   sranom(hash(haslo));

   for (i=0; i< rozmiar_danych; i++)
       dane_wy[i] = dane_we[i] ^ random();
}

Jak wida� ca�a funkcja hash() musi by� tajna a nie tylko klucz gdy� XOR ma
to do siebie �e je�li mamy funkcj� XOR, kt�ra
xoruje nam sw�j parametr z naszym tajnym kluczem to tajny klucz  = XOR(0)

Tak wi�c je�eli upublicznimy ca�y nasz algorytm poza funkcj� hash() to
kryptoanaliza (dla osoby znaj�cej swoje has�o) sprowadza si� do znalezienia
algorytmu u�ytego w tej�e funkcji. Umiej�cy pos�ugiwa� si� debbugerem nie
b�d� mieli z ni� raczaj �adnych probelm�w.
Nie jest to jednak nic przykrego, gdy� kryptografia ma na celu chronienie
danych przed innymi a nie przed samym sob� i �aden pakiet do
kodowania poczty nie utrudnia zdekodowania maili kt�re przychodz� do
w�a�ciciela klucza kt�rym by�y kodowane ale uniemo�liwia odczytanie danych
tym, kt�rzy klucza nie posiadaj�.



Aby skomplikowa� �ycie crackerom nale�y uczyni� funkcj� hash() maksymalnie
trudn� do analizy i debbugowania. Jest to lepszy pomys� ni� komplikowanie w
ten spos�b ca�ej procedury kodowania, gdy� funkcja hash() jest uruchamiana
wielokrotnie rzadziej ni� linijka
dane_wy[i] = dane_we[i]] ^ random(). St�d kodowanie i dekodowanie danych ma
szans� by� do�� szybk� operacj�.

Przypomn� tylko, �e utajnianie funkcji hash() ma na celu powstrzymanie
w�a�ciciela od r�cznego zdekodowania danych i nie ma wp�ywu na moc algorytmu
jako takiego. Nawet ja jako osoba, kt�ra napisa�a t� funkcj� i tak musia�bym
wykonywa� te 2^32 pr�b aby odczyta� dane graczy, kt�rych hase� nie znam.

Na moc algorytmu ma natomiast wp�yw sama funkcja hash(). Oto przyk�ad:
typ integer ma cztery bajty d�ugo�ci (na procesorach 32-bitowych) - czyli
cztery znaki.
Wyobra�my sobie, �e nasza funkcja hasuj�ca po prostu u�ywa znak�w has�a jako
integera
(czyli cos w stylu (unsigned integer) {'p','a','s','s'} )
W takiej sytuacji nie b�dziemy mieli nigdy rezultatu tej funkcji wynosz�cego
1,2,3,4 czy 5. I jak si� zastanowimy to wog�le b�dziemy mieli
co najwy�ej jakie� 90^4 mo�liwo�ci (czyli wszystkie litery, cyfry i inne
temu podobne znaki) czyli sporo mniej ni� 2^32 (jakie� sto razy mniej).
A jak wezmie sie pod uwage fakt, ze wiekszosc ludzi wybiera proste hasla to
dostajemy cos oko�o 30^4 a to juz tylko 810000 mo�liwo�ci zatem prawie tak
jakby wog�le nie kodowane.

Mam nadziej�, �e nawet je�li ca�y ten wyw�d nikomu si� nie przyda to chocia�
kto� doczyta� do tej linijki...

Arek