user: "Jacek23"

witam czy to dobry program i wygodny? zalezy mi na: niszczeniu danych szyfrowaniu poczty zabezpieczeniu danych przed rozszyfrowaniem .................... zabezpieczenia maja zabezpieczac dane przed wszystkimi a nie tylko przed ciocia lub bratem. -- jacek23@post.pl gg: 207344.

user: "Stachu 'Dozzie' K."

On 10.05.2006, Jacek23 wrote: > witam > czy to dobry program i wygodny? > zalezy mi na: > niszczeniu danych > szyfrowaniu poczty > zabezpieczeniu danych przed rozszyfrowaniem > .................... > zabezpieczenia maja zabezpieczac dane przed wszystkimi a nie tylko przed > ciocia lub bratem. No nie wiem... Jeśli pisali go ci sami ichniejsi specjaliści od kryptografii i bezpieczeństwa, którzy piszą na tę grupę, to raczej bym mu nie ufał. Osobiście wolę Loop-AES-a i GnuPG. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): > On 10.05.2006, Jacek23 wrote: >> witam >> czy to dobry program i wygodny? >> zalezy mi na: >> niszczeniu danych >> szyfrowaniu poczty >> zabezpieczeniu danych przed rozszyfrowaniem >> .................... >> zabezpieczenia maja zabezpieczac dane przed wszystkimi a nie tylko przed >> ciocia lub bratem. > > No nie wiem... Jeśli pisali go ci sami ichniejsi specjaliści od > kryptografii i bezpieczeństwa, którzy piszą na tę grupę, to raczej bym > mu nie ufał. Osobiście wolę Loop-AES-a i GnuPG. > 1) Jak by to Tobie powiedzieć, Stachu. "Twoje" otp złamałem jakiś czas temu i to nawet nie przez słabość md5 czy sha1 tylko totalnej głupoty "funkcji skrótu" stosowanej do uproszczenia oryginalnego sktótu do 64bitów. Zobacz sam w rfc jak to wygląda a zapewniam Ciebie że się załamiesz. Jak mówiłem(pisałem) jestem praktykiem, teoria to minie interesowała na studiach. To tyle na temat bezpiecznego otp. 2) Co do loopaes to fajne ale dla linuxa, tutaj jest mowa o windzie. 3) Co do TS NxG najpierw go złam później krytykuj. PS Przypominasz mi naszych polityków, w słowach fajnie z czynami gorzej. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 10.05.2006, Marcin Gabryszewski wrote: > Stachu 'Dozzie' K. napisał(a): >> On 10.05.2006, Jacek23 wrote: >>> witam >>> czy to dobry program i wygodny? >>> zalezy mi na: >>> niszczeniu danych >>> szyfrowaniu poczty >>> zabezpieczeniu danych przed rozszyfrowaniem >>> .................... >>> zabezpieczenia maja zabezpieczac dane przed wszystkimi a nie tylko przed >>> ciocia lub bratem. >> >> No nie wiem... Jeśli pisali go ci sami ichniejsi specjaliści od >> kryptografii i bezpieczeństwa, którzy piszą na tę grupę, to raczej bym >> mu nie ufał. Osobiście wolę Loop-AES-a i GnuPG. >> > 1) > Jak by to Tobie powiedzieć, Stachu. "Twoje" otp złamałem jakiś czas temu > i to nawet nie przez słabość md5 czy sha1 tylko totalnej głupoty > "funkcji skrótu" stosowanej do uproszczenia oryginalnego sktótu do > 64bitów. ROTFL, że tak powiem. Umiesz odwracać MD5? Nawet skrócone? Możesz wskazać jakiś papier o tym traktujący? A może znalazłeś inną metodę na atak na OTP? Masz może pod ręką implementację albo chociaz opis? I koniecznie szacunkowy czas łamania pojedynczego hasła. Mnie wyszło koło 15 lat, przy częstotliwości sprawdzania hasza około 1GHz. Taki prosty atak brute-force. > 2) > Co do loopaes to fajne ale dla linuxa, tutaj jest mowa o windzie. Nikt nie mówił, że to ma być Windows. > 3) > Co do TS NxG najpierw go złam później krytykuj. Najpierw dajcie kod źródłowy i/lub dokumentację programistyczną, później się zastanowimy nad analizą. Na razie ty kompromitujesz firmę swoją wiedzą z kryptografii, stąd mój brak zaufania do waszych produktów z kryptografią związanych. Z drugiej strony, nie mam żadnych powodów, żeby wierzyć w poprawną implementację waszych okołokryptograficznych aplikacji (bo nikt mi takich powodów nie dostarczył). Miałbym zaufać na piękne oczy? > PS > Przypominasz mi naszych polityków, w słowach fajnie z czynami gorzej. Sugerujesz, że nie jestem praktykiem? Pomyślmy... atak kleptograficzny na IKE to trochę mało praktyczna rzecz... -- Feel free to correct my English Stanislaw Klekot

user: "gary0"

> > 1) > > Jak by to Tobie powiedzieć, Stachu. "Twoje" otp złamałem jakiś czas temu > > i to nawet nie przez słabość md5 czy sha1 tylko totalnej głupoty > > "funkcji skrótu" stosowanej do uproszczenia oryginalnego sktótu do > > 64bitów. > > ROTFL, że tak powiem. Umiesz odwracać MD5? Nawet skrócone? Możesz > wskazać jakiś papier o tym traktujący? A może znalazłeś inną metodę na > atak na OTP? Masz może pod ręką implementację albo chociaz opis? > I koniecznie szacunkowy czas łamania pojedynczego hasła. Mnie wyszło > koło 15 lat, przy częstotliwości sprawdzania hasza około 1GHz. Taki > prosty atak brute-force. > Ale przecież tu nie mam mowy o odwróceniu md5. Myślę że Dozzie nawet nie doczytał tego co ten człowiek z GDATY napisał. Atak na sktót 64bitowy został z powodzeniem przeprowadzony w mojej firmie już ponad rok temu. na bazie md5 600 GB ze procentem trafiń > 80% skrót 64 bitowy w otp dla md5 jest bzdurą bo wygłąda on tak b64[n] = md5[n] xor md5[n+7]; powiedzmy że md5 = 12 34 56 78 00 00 00 00 00 00 00 00 AB CD EF 00 to b64 = 12 34 56 78 AB CD EF 00. ale istnieje 2 do 64 sktótów md5 które spełnią to równanie(sic!!!) bo md5 który wygląda tak 12 34 56 78 AB CD EF 00 00 00 00 00 00 00 00 00 a także 00 00 00 00 00 00 00 00 12 34 56 78 AB CD EF czyli jeżeli ktoś zbuduje sobie bazę danych sktórów md5 dla wartości 64bitówych(wystardzy nawet mała 2^32 skrótów) to póżniej przeszukuje ją pod kątem odwrócenia tego równiana b64[n] = md5[n] ^ md5[n+7] i ma już poprzedzające hasło logowania. Wystarczy tylko zamienić znalezioną watość na 6-word-value jo

user: "Stachu 'Dozzie' K."

On 14.05.2006, gary0 wrote: >> > 1) >> > Jak by to Tobie powiedzieć, Stachu. "Twoje" otp złamałem jakiś czas temu >> > i to nawet nie przez słabość md5 czy sha1 tylko totalnej głupoty >> > "funkcji skrótu" stosowanej do uproszczenia oryginalnego sktótu do >> > 64bitów. >> >> ROTFL, że tak powiem. Umiesz odwracać MD5? Nawet skrócone? Możesz >> wskazać jakiś papier o tym traktujący? A może znalazłeś inną metodę na >> atak na OTP? Masz może pod ręką implementację albo chociaz opis? >> I koniecznie szacunkowy czas łamania pojedynczego hasła. Mnie wyszło >> koło 15 lat, przy częstotliwości sprawdzania hasza około 1GHz. Taki >> prosty atak brute-force. >> > > Ale przecież tu nie mam mowy o odwróceniu md5. Jak to nie? Tylko o czym niby? O generowaniu kolizji? > Myślę że Dozzie nawet nie > doczytał tego co ten człowiek z GDATY napisał. Atak na sktót 64bitowy został > z powodzeniem przeprowadzony w mojej firmie już ponad rok temu. na bazie md5 > 600 GB ze procentem trafiń > 80% > skrót 64 bitowy w otp dla md5 jest bzdurą > bo wygłąda on tak > b64[n] = md5[n] xor md5[n+7]; > powiedzmy że md5 = 12 34 56 78 00 00 00 00 00 00 00 00 AB CD EF 00 > to b64 = 12 34 56 78 AB CD EF 00. > ale istnieje 2 do 64 sktótów md5 które spełnią to równanie(sic!!!) No zgadza się. Ale co to ma do rzeczy? Nadal masz 2^64 możliwych _różnych_ wartości skróconego MD5. To jest 2^64 / 2^30 = 2^34 G tych skrótów, tak na sztuki. Trochę dużo, jak na mój gust. > bo md5 który wygląda tak 12 34 56 78 AB CD EF 00 00 00 00 00 00 00 00 00 > a także 00 00 00 00 00 00 00 00 12 34 56 78 AB CD EF > czyli jeżeli ktoś zbuduje sobie bazę danych sktórów md5 dla wartości > 64bitówych Pytanie kontrolne: jak są w bazie trzymane te skróty, jak wygląda wyszukiwanie hasza i odtworzenie poprzedzającej go wartości? Co jest w bazie kluczem, a co wartością? To, wbrew pozorom, dość istotny szczegół ataku, bez którego dalej można tylko zgadywać, o co chodzi. > (wystardzy nawet mała 2^32 skrótów) Policzmy prawdopodobieństwo trafienia: strzelając jednym skrótem mamy szanse trafienia jak 2^32 * 2^(-64) = 2^(-32) strzelając setką haseł jednorazowych szanse trafienia są mniej więcej jak 100 * 2^(-32) = 2^(-24) Trochę mało, nieprawdaż? Ja wiem, proces Markova, prawdopodobieństwo dąży do jedynki, ale weź skutecznie podsłuchuj ofiarę w nieskończoność. No dobra. Przekonałeś mnie. Wykombinowałem sam, co można zrobić dla 64-bitowego MD5. Tylko że mój pomysł nie ma absolutnie nic wspólnego z tym, co tu napisałeś, tak więc nadal czekam na objaśnienia. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): > > No dobra. Przekonałeś mnie. Wykombinowałem sam, co można zrobić dla > 64-bitowego MD5. Tylko że mój pomysł nie ma absolutnie nic wspólnego > z tym, co tu napisałeś, tak więc nadal czekam na objaśnienia. > Nie wiem gdzie pracuje gary0 ani jak to robił, opisze "mój" atak. 1)budujemy bazę int64 i64val - index unikalny int64 i64xor - skrót 64 bitowy( ten xor z dokumentacji otp ) hasa md5 wartości i64val, pole indeksowane 2)wypełniamy bazę, i64val = warość 64bitowa,(losowana, kolejna, jak kto chce) liczymy md5v = md5(i64val), i64xor = xor64(md5v); czyli nasz xor md5v[n]^md5v[n+7]; ja zbudowałem baze 2 do 34(dwa dni roboty). baza garego0, była patrząc po tylko po wielkości bazy, większa. Na moje oko 2 do 36 może więcej. Zależy od organizacji i użytej bazy. 3)przechwytujemy hasło(6 słów) i odwracamy do wartości 64bitowej(pass64). 4)szukamy w bazie (select * from otp where i64xor = pass64). Jak nic nie ma, to pech. Jak jest, to zamieniamy i64val na 6 słów i logujemy się :). U mnie na 10000 przeszukanych haseł znaleziono 3!!! Jak dla mnie 3/10000 to jest bardzo duże prawdopodobieństwo, eh gdyby takie było w lotku. Baz już nie mam bo trochę zajmowały. Ale sprawdź sobie sam. To jest naprawdę prosty atak. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 22.05.2006, Marcin Gabryszewski wrote: > Stachu 'Dozzie' K. napisał(a): >> >> No dobra. Przekonałeś mnie. Wykombinowałem sam, co można zrobić dla >> 64-bitowego MD5. Tylko że mój pomysł nie ma absolutnie nic wspólnego >> z tym, co tu napisałeś, tak więc nadal czekam na objaśnienia. >> > Nie wiem gdzie pracuje gary0 ani jak to robił, opisze "mój" atak. > 1)budujemy bazę > int64 i64val - index unikalny > int64 i64xor - skrót 64 bitowy( ten xor z dokumentacji otp ) hasa md5 > wartości i64val, pole indeksowane > > 2)wypełniamy bazę, > i64val = warość 64bitowa,(losowana, kolejna, jak kto chce) > liczymy md5v = md5(i64val), > i64xor = xor64(md5v); czyli nasz xor md5v[n]^md5v[n+7]; > > ja zbudowałem baze 2 do 34(dwa dni roboty). baza garego0, była patrząc > po tylko po wielkości bazy, większa. Na moje oko 2 do 36 może więcej. > Zależy od organizacji i użytej bazy. > > 3)przechwytujemy hasło(6 słów) i odwracamy do wartości 64bitowej(pass64). > > 4)szukamy w bazie (select * from otp where i64xor = pass64). Jak nic nie > ma, to pech. Jak jest, to zamieniamy i64val na 6 słów i logujemy się :). > > > U mnie na 10000 przeszukanych haseł znaleziono 3!!! Jak dla mnie 3/10000 > to jest bardzo duże prawdopodobieństwo, eh gdyby takie było w lotku. Mnie wychodzi, że to powinno być jakoś dziesięć razy mniejsze prawdopodobieństwo. Ale ja się nie znam na odejmowaniu wykładników. Tak czy siak, do skutecznego (pdbo > 0.01) zaatakowania mojego hasła potrzebujesz, tak na oko, około 2^27 moich prób logowania. Trochę mało praktyczne, jak dla mnie. Ale znowu, ja nie umiem liczyć, bo nie pracuję w firmie sprzedającej kryptografię snake-oil. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): >> 2) >> Co do loopaes to fajne ale dla linuxa, tutaj jest mowa o windzie. > > Nikt nie mówił, że to ma być Windows. Mówił(w domyśle), bo TS NxG jest TYLKO na windę. > >> 3) >> Co do TS NxG najpierw go złam później krytykuj. > > Najpierw dajcie kod źródłowy i/lub dokumentację programistyczną, później > się zastanowimy nad analizą. Może jaszcze prawa majątkowe. A poważnie, kilka informacji o programie. 1)Trzy algorytmy (aes, serpent, twofish) wszystkie w wersji 256 bitowej. 2)Implementacja referencyjna nist'u (gladman) dla finalistów aes. 3)Weryfikacja użytkownika(hasła), odczytanie klucza dyskowego a) tworzenie : 256 krotny md5 na wprowadzonym haśle, 257 skrót szyfrowany blowfish'em gdzie klucz to jest 256 skrót. b) sprawdzenie : 256 krotny md5 na wprowadzonym haśle, deszszyfracja zapisanego 257 skrótu. Porównanie skrótów nr 257 i odszyfrowanego. Zrobienie następnych 256 rund md5, gdzie runda 513 i 514 to klucz do deszyfracji(aes) MK(256bitów) dla dysków. 4) Dodatkowo przy pierwszym uruchomieniu programu następuje generowanie 256 bitowego klucza głównego(dla aes), który jest dodatkowo wykorzystywany przy szyfrowaniu sektorów wirtualnych sejfów. 5) bloki sektora szyfrowane w trybie cbc. gdzie IV to xor klucza głównego i sktót(md5) numeru sektora. Co jeszcze chcesz wiedzieć? > > Na razie ty kompromitujesz firmę swoją wiedzą z kryptografii, stąd mój > brak zaufania do waszych produktów z kryptografią związanych. W którym miejscu?? Że popieram(ufam) takich ludzi jak Schneier, Gutmann, czy pani Wang. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): >> U mnie na 10000 przeszukanych haseł znaleziono 3!!! Jak dla mnie 3/10000 >> to jest bardzo duże prawdopodobieństwo, eh gdyby takie było w lotku. > > Mnie wychodzi, że to powinno być jakoś dziesięć razy mniejsze > prawdopodobieństwo. > Ale ja się nie znam na odejmowaniu wykładników. Tak czy siak, do > skutecznego (pdbo > 0.01) zaatakowania mojego hasła potrzebujesz, tak na > oko, około 2^27 moich prób logowania. Trochę mało praktyczne, jak dla > mnie. Ale znowu, ja nie umiem liczyć, bo nie pracuję w firmie > sprzedającej kryptografię snake-oil. > Widzisz, odejmować wykładniki to ja także potrafię, ale to jest PRAWDOPODOBIEŃŚTWO. U mnie przy 10000 prób znalazłem 3, więc podałem prawdopodobieństwo realnego(zrobionego w rzeczywistości) mojego ataku. A nie prawdopobobieństo w ogóle dal tego typu operacji. Ludzie grają w totka i wygrywają jednym zakładem 6, powiedz im że powinni wypełnić ileś tam milionów kuponów( 1 z 46, 1 z 45 itd możliwości ). Ja powiedziałem że otp złamałem i koniec. W dodatku okazuje się że nie tylko ja widzę słabość tego 64 bitowego skrótu. Na dzień dzisiejszy 64 bity to jest mało jeżeli chodzi o security. Ja w domowych warunkach robię bazę 2 do 34, nie widzę problemu by jakaś firma nie miała bazy 2 do 48 czy więcej. Zaś przeszukanie indeksowanych baz to chwila. Najzabawniejsze teraz jest to że ty nawet nie negujesz tego że to jest do zrobienia w praktyce, a dalej się sprzeczasz czort wie o co. Dlaczego nie wykonasz tego ataku sam? Dwa, trzy dni roboty dla wygenerowania bazy a potem tylko testy. PS Nie wiem jakiej bazy użył gary0 że tylko przy 600GB otrzymał aż 80%. Może coś jeszcze podpowie. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 22.05.2006, Marcin Gabryszewski wrote: > Stachu 'Dozzie' K. napisał(a): >>> U mnie na 10000 przeszukanych haseł znaleziono 3!!! Jak dla mnie 3/10000 >>> to jest bardzo duże prawdopodobieństwo, eh gdyby takie było w lotku. >> >> Mnie wychodzi, że to powinno być jakoś dziesięć razy mniejsze >> prawdopodobieństwo. >> Ale ja się nie znam na odejmowaniu wykładników. Tak czy siak, do >> skutecznego (pdbo > 0.01) zaatakowania mojego hasła potrzebujesz, tak na >> oko, około 2^27 moich prób logowania. Trochę mało praktyczne, jak dla >> mnie. Ale znowu, ja nie umiem liczyć, bo nie pracuję w firmie >> sprzedającej kryptografię snake-oil. >> > Widzisz, odejmować wykładniki to ja także potrafię, ale to jest > PRAWDOPODOBIEŃŚTWO. U mnie przy 10000 prób znalazłem 3, więc podałem > prawdopodobieństwo realnego(zrobionego w rzeczywistości) mojego ataku. A > nie prawdopobobieństo w ogóle dal tego typu operacji. W rachunku prawdopodobieństwa jest jeszcze coś takiego jak wariancja. > Ja powiedziałem że otp złamałem i koniec. A ja złamałem Rijndaela. Też mogę sobie tak powiedzieć. > W dodatku okazuje się że nie > tylko ja widzę słabość tego 64 bitowego skrótu. Na dzień dzisiejszy 64 > bity to jest mało jeżeli chodzi o security. Znowu puste słowa. Może przestań rzucać sloganami? Czy ty zdajesz sobie sprawę, _dlaczego_ to jest mało? I w których zastosowaniach? Bo, wbrew pozorom, zastosowanie ma tu bardzo dużo do rzeczy. > PS > Nie wiem jakiej bazy użył gary0 że tylko przy 600GB otrzymał aż 80%. > Może coś jeszcze podpowie. Nie sądzę. Dla mnie to liczby wzięte z sufitu, jeśli nie żywcem zmyślone. Nie powiedział ani słówka o samym ataku, więc szczerze wątpię w to, że miał z nim do czynienia. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): >> Ja powiedziałem że otp złamałem i koniec. > > Też mogę sobie tak powiedzieć. > Tylko ja dałem dowód, sposób ataku który możesz sam przeprowadzić. Jeszcze raz proszę, przeprowadź ten atak sam. Potem podyskutujemy. > A ja złamałem Rijndaela. I oczywiście potrafisz przedstawić sposób ataku na zwycięzce nist'u krok po kroku tak jak ja :) >> PS >> Nie wiem jakiej bazy użył gary0 że tylko przy 600GB otrzymał aż 80%. >> Może coś jeszcze podpowie. > > Nie sądzę. Dla mnie to liczby wzięte z sufitu, jeśli nie żywcem > zmyślone. Nie powiedział ani słówka o samym ataku, więc szczerze wątpię > w to, że miał z nim do czynienia. > Cóż ja nie pojadę twoim stylem i nie będę krytykował i oskarżał bez podstaw. Poczekam na odpowiedź. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 22.05.2006, Marcin Gabryszewski wrote: > Stachu 'Dozzie' K. napisał(a): >>> 2) >>> Co do loopaes to fajne ale dla linuxa, tutaj jest mowa o windzie. >> >> Nikt nie mówił, że to ma być Windows. > Mówił(w domyśle), bo TS NxG jest TYLKO na windę. > >> >>> 3) >>> Co do TS NxG najpierw go złam później krytykuj. >> >> Najpierw dajcie kod źródłowy i/lub dokumentację programistyczną, później >> się zastanowimy nad analizą. > Może jaszcze prawa majątkowe. I ja mam zaufać szyfrom, których nie widzę, dobrze zrozumiałem? "To jest bezpieczne, zaufaj nam"? > A poważnie, kilka informacji o programie. > > 1)Trzy algorytmy (aes, serpent, twofish) wszystkie w wersji 256 bitowej. > 2)Implementacja referencyjna nist'u (gladman) dla finalistów aes. I ja jestem w stanie zweryfikować tę implementację referencyjną, tak? > 3)Weryfikacja użytkownika(hasła), odczytanie klucza dyskowego > a) tworzenie : 256 krotny md5 na wprowadzonym haśle, 257 skrót ^^^ > szyfrowany blowfish'em gdzie klucz to jest 256 skrót. > b) sprawdzenie : 256 krotny md5 na wprowadzonym haśle, deszszyfracja > zapisanego 257 skrótu. Porównanie skrótów nr 257 i odszyfrowanego. > Zrobienie następnych 256 rund md5, gdzie runda 513 i 514 to klucz do ^^^ > deszyfracji(aes) MK(256bitów) dla dysków. To miało być 256 nieprzewidywalnych bitów? Trochę się nie udało. Tak jak pierwiastek się nie udało. Nadal 128 bitów jest nieprzewidywalnych, co na dzisiaj zapewnia bezpieczeństwo z Rijndaelem, ale miało być tego znacznie więcej. Pomysł na atak: znajdźmy takie 128-bitowe x256, że E_x256(MD5(x256)) jest równe znanemu kryptogramowi 257-go skrótu. Tylko Blowfish broni tu x. To całkiem sporo, tak na oko, ale mogło być znacznie więcej. > 4) Dodatkowo przy pierwszym uruchomieniu programu następuje generowanie > 256 bitowego klucza głównego(dla aes), który jest dodatkowo > wykorzystywany przy szyfrowaniu sektorów wirtualnych sejfów. > 5) bloki sektora szyfrowane w trybie cbc. gdzie IV to xor klucza > głównego i sktót(md5) numeru sektora. ^^^ O. A podobno "MD5 is dead", bo tak powiedział Schneier. Bardzo konsekwentnie, przyznaję. Uszkodzimy klucz główny na jednym bicie. Ciekawe, jakimi błędami sypnie sejf... A może z tych błędów uda się odzyskać jakieś bity zaszyfrowanego tekstu? > Co jeszcze chcesz wiedzieć? Co to jest i jak długi jest wspomniany przez ciebie sektor? No i problemem są uszkodzenia sejfu z zewnątrz, tzn. kryptogramu. Przed atakującym otwiera się cały toolbox cut'n'paste. Podsumowując: w paru miejscach mogło być dużo, dużo lepiej przy praktycznie żadnym dodatkowym wysiłku, a jeden problem na razie wisi nierozwiązany. Ile dostanę za ekspertyzę? >> Na razie ty kompromitujesz firmę swoją wiedzą z kryptografii, stąd mój >> brak zaufania do waszych produktów z kryptografią związanych. > W którym miejscu?? > Że popieram(ufam) takich ludzi jak Schneier, Gutmann, czy pani Wang. Nie. Że ślepo (bez zrozumienia) powtarzasz wyrwane z kontekstu stwierdzenia. Niekonsekwentnie do tego, bo przecież według ciebie MD5 zostało złamane i nie nadaje się do niczego. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): > I ja mam zaufać szyfrom, których nie widzę, dobrze zrozumiałem? "To jest > bezpieczne, zaufaj nam"? Większość firm od security nie daje źródeł(securedoc, safeguard, bestcrypt i wiele innych im też "musisz" zaufać). "Musisz" napisałem w "" bo wcale nie muszisz kupisz sofu któremu nie ufasz. A więcej ja sam nie kupuję softu któremu nie ufam. Z drugiej strony, nie wiesz jak w samochodzie działają systemy bezpieczeństwa, a samochód kupisz bez patrzenia w projekt, oglądania fabryki itp. A w samochodzie chodzi o rzecz najważniejszą życie. > I ja jestem w stanie zweryfikować tę implementację referencyjną, tak? > A powiedz mi po jaką czorta mam się męczyć z implementacją z dokumentacji(co w przeszłości robiłem) sokoro już to zrobiono i zrobili to ludzie naprawdę znający się na rzeczy. > Pomysł na atak: znajdźmy takie 128-bitowe x256, że E_x256(MD5(x256)) > jest równe znanemu kryptogramowi 257-go skrótu. Tylko Blowfish broni tu > x. To całkiem sporo, tak na oko, ale mogło być znacznie więcej. Pamiętaj że projekt ma ponad dwa lata, teraz jest już nowy. oparty o sha256 i 1024 rundy, zamiast blowfisha jest jest aes256. > > O. A podobno "MD5 is dead", bo tak powiedział Schneier. Bardzo > konsekwentnie, przyznaję. A ja się powtórzę, ten projekt ma ponad 2 lata. Czyli powstał przed tymi słowami. Poza tym, tu md5 jest użyty jako "seed"(czego niekwestionowałem), a nie jako security( np. otp ) > > Uszkodzimy klucz główny na jednym bicie. Ciekawe, jakimi błędami sypnie > sejf... A może z tych błędów uda się odzyskać jakieś bity zaszyfrowanego > tekstu? wszystko się wysypie :(. Po otworzeniu sejfu dysk będzie wyglądał jak niesformatowany. Po to są kopie bezpieczeństwa kluczy(wymuszane zresztą na userze) i sam klucz jest przetrzymywany w dwóch miejscach. > > Co to jest i jak długi jest wspomniany przez ciebie sektor? Sektor to najmniejsza jednostka która może być zapisana przez dysk. Nawet jak zapiszesz jeden bajt to dysk i tak zapisze 512 bajtów. Na dzień dzisiejszy nie znam dysku o innej długości sektora niż 512. Kiedyś chyba simens wypuścił dysko o długości sektora 514 bajtów. > > No i problemem są uszkodzenia sejfu z zewnątrz, tzn. kryptogramu. > Przed atakującym otwiera się cały toolbox cut'n'paste. pamiętaj że uszkodzić możesz tylko cały sektor 512 bajtów. Jeżeli zmienisz jeden bajt to zmienisz cały sektor, a przynajmniej jeden blok(aes, twofish, serpent są w końcu blokowymi szyframi, 16 bajtów). > > Podsumowując: w paru miejscach mogło być dużo, dużo lepiej przy > praktycznie żadnym dodatkowym wysiłku, Ale jak wspomniałem już kończymy wersję znacznie poprawioną. a jeden problem na razie wisi > nierozwiązany. > > > Ile dostanę za ekspertyzę? :), tak ekspertyza(właściwie to nawet dużo głębsza) to była w projekcie więc zanim jeszcze zabraliśmy się do pracy stricte programistycznej. > > Nie. Że ślepo (bez zrozumienia) powtarzasz wyrwane z kontekstu > stwierdzenia. Niekonsekwentnie do tego, bo przecież według ciebie MD5 > zostało złamane i nie nadaje się do niczego. > Jak cytujesz to dokładnie. md5 nie nadaje się do niczego związanego z security. Jeżeli ktoś chce używać md5 zamiast crc jak najbardziej polecam, jako seed lub cały generator liczb pseudo tak samo polecam. I ostatni raz powtórzę, ten projekt ma około trzy lata, a sam program ponad dwa. Więc powstał zanim md5 padł. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 29.05.2006, Marcin Gabryszewski wrote: >> Pomysł na atak: znajdźmy takie 128-bitowe x256, że E_x256(MD5(x256)) >> jest równe znanemu kryptogramowi 257-go skrótu. Tylko Blowfish broni tu >> x. To całkiem sporo, tak na oko, ale mogło być znacznie więcej. > Pamiętaj że projekt ma ponad dwa lata, teraz jest już nowy. oparty o > sha256 i 1024 rundy, zamiast blowfisha jest jest aes256. To teraz wytłumacz się z tej ilości iteracji. >> O. A podobno "MD5 is dead", bo tak powiedział Schneier. Bardzo >> konsekwentnie, przyznaję. > A ja się powtórzę, ten projekt ma ponad 2 lata. Czyli powstał przed tymi > słowami. Poza tym, tu md5 jest użyty jako "seed"(czego > niekwestionowałem), a nie jako security( np. otp ) Seed? Znaczy "seed, z którego będzie zrobiony klucz"? I to według ciebie nie jest "security"? Poza tym do tej pory nie podałeś żadnego sensownego ataku na OTP z MD5. Dlaczego więc nadal uparcie twierdzisz, że MD5 się do tego nie nadaje? >> Uszkodzimy klucz główny na jednym bicie. Ciekawe, jakimi błędami sypnie >> sejf... A może z tych błędów uda się odzyskać jakieś bity zaszyfrowanego >> tekstu? > wszystko się wysypie :(. Po otworzeniu sejfu dysk będzie wyglądał jak > niesformatowany. Niby dlaczego? Przecież przekłamany jest tylko _jeden bit_ tekstu jawnego, a z opisu, który przedstawiłeś, nie widać ani śladu czegoś, co mogłoby rozsypać zawartość. No chyba że nie rozumiesz, co to jest "initial vector" w trybie CBC. >> Co to jest i jak długi jest wspomniany przez ciebie sektor? > Sektor to najmniejsza jednostka która może być zapisana przez dysk. > Nawet jak zapiszesz jeden bajt to dysk i tak zapisze 512 bajtów. > Na dzień dzisiejszy nie znam dysku o innej długości sektora niż 512. > Kiedyś chyba simens wypuścił dysko o długości sektora 514 bajtów. To po co wspominasz o sektorze _dyskowym_? Przecież to byt zupełnie niezależny od tego, _co_ i _jak_ szyfrujemy. >> No i problemem są uszkodzenia sejfu z zewnątrz, tzn. kryptogramu. >> Przed atakującym otwiera się cały toolbox cut'n'paste. > pamiętaj że uszkodzić możesz tylko cały sektor 512 bajtów. Jeżeli > zmienisz jeden bajt to zmienisz cały sektor, a przynajmniej jeden > blok(aes, twofish, serpent są w końcu blokowymi szyframi, 16 bajtów). Ustaliliśmy (a raczej ty podałeś), że sektor to są dane zapisane na dysk twardy. Czyli to dysk twardy coś sobie z tym robi, a to nie ma nic wspólnego ze szyfrowanymi danymi. >> Podsumowując: w paru miejscach mogło być dużo, dużo lepiej przy >> praktycznie żadnym dodatkowym wysiłku, > Ale jak wspomniałem już kończymy wersję znacznie poprawioną. Jeśli poprawianie miałoby polegać na zmianie algorytmów i ilości iteracji, to _nic_ nie poprawiliście. > a jeden problem na razie wisi >> nierozwiązany. >> >> >> Ile dostanę za ekspertyzę? >:), tak ekspertyza(właściwie to nawet dużo głębsza) to była w projekcie > więc zanim jeszcze zabraliśmy się do pracy stricte programistycznej. Właśnie widzę, i stąd 256 bitów IV, z których tylko połowa jest nieprzewidywalna. Stąd oparcie bezpieczeństwa klucza wyłącznie o algorytm szyfrowania, podczas gdy można było dorzucić coś jeszcze. Stąd brak kontroli integralności danych. I mówisz, że to analizowaliście? Trzeba było zaprosić do rozmowy jakiegoś kryptologa albo chociaż studenta kryptografii. >> Nie. Że ślepo (bez zrozumienia) powtarzasz wyrwane z kontekstu >> stwierdzenia. Niekonsekwentnie do tego, bo przecież według ciebie MD5 >> zostało złamane i nie nadaje się do niczego. >> > Jak cytujesz to dokładnie. md5 nie nadaje się do niczego związanego z > security. Jeżeli ktoś chce używać md5 zamiast crc jak najbardziej > polecam, jako seed lub cały generator liczb pseudo tak samo polecam. I niby generator liczb pseudolosowych nie jest związany z "security", tak? I co dokładnie rozumiesz pod słowem "seed"? Bo chyba nie ziarno dla generatora losowego? -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): > Seed? Znaczy "seed, z którego będzie zrobiony klucz"? I to według ciebie > nie jest "security"? Aj, nie czytałeś dokładnie. Istnieją dwa klucze!!! jeden to MK (masterkey 256bitów i jest to klucz dla algorytmu, do wygenerowania niego są wykorzystywane ruchy myszą i klawisze) drugi to klucz główny(pseudolosowy) generowany przy starcie aplikacji używany m.in. jako jedna ze składowych do iv dla algorytmu. > Poza tym do tej pory nie podałeś żadnego sensownego > ataku na OTP z MD5. a to ciekawe??? a próbowałeś powtórzyć atak, nie?? To zrób to. Później pogadamy. Bo przy moim wyniku 3/10000 otp nie ma sensu. To już pin 4 cyfrowy jest mocniejszy i tu nie ma możliwości wyliczenia hasła jak w otp. > Dlaczego więc nadal uparcie twierdzisz, że MD5 się > do tego nie nadaje? Jak cytujesz to dokładnie. Twierdziłem(i dalej twierdzę) że otp stwarza potencjalnie duże niebezpieczeństwo przy ataku na otp takim jak mój, w szególności dla md5, i to nie dlatogo że użyty został md5, ale ze względu na 64 bitową funkcję skrótu wykorzystywaną dla tego algorytmu. Chyba trzeba będzie zacząć nowy wątek tylko o otp bo to jest mocno OT. > > Niby dlaczego? Przecież przekłamany jest tylko _jeden bit_ tekstu > jawnego, a z opisu, który przedstawiłeś, nie widać ani śladu czegoś, co > mogłoby rozsypać zawartość. No chyba że nie rozumiesz, co to jest > "initial vector" w trybie CBC. A tak w ogóle to może byś sie zdecydował czy jeden bit w tekście jawnym(co rozumiem jeden bit w sektorze do zaszyfrowania, czyli najnormalniejszy atak tekstem jawnym) czy w kluczu głównym. 1)Jeżeli zmienię jeden bit w kluczu głównym(nie MK) to md5 z tego da mi całkowicie inny wynik, czyli cały iv będzie inny!!! czyli pierwszy jak i kolejne bloki w sektorze także. 2)Jeżeli zmienię jeden bit w MK to w ogóle rozmowa nie ma sensu chyba że znasz atak na aes czy twofish. 3) Co do tekstu jawnego to zależy który bit zmienisz, jak ostatni to ostatni blok w sektorze zostanie uszkodzony(inny kryptogram 16 bajtów). Jeżeli pierwszy to cały sektor wyleci w kosmos. > > To po co wspominasz o sektorze _dyskowym_? Przecież to byt zupełnie > niezależny od tego, _co_ i _jak_ szyfrujemy. Nie masz racji. Jest to bardzo ważna dana. Bo jeżeli sektor(512bajów) idzie w trybie cbc to znaczy że kryptogram jest wynikiem 32( 32*16 = 512) szyfrowań np aes w trybie cbc. więc całkowity obraz zaszyfrowanego dysku składa się z 32 bloków po 16 bajtów które układają sie w niezależne bloki po 512 bajtów. > Ustaliliśmy (a raczej ty podałeś), że sektor to są dane zapisane na > dysk twardy. Czyli to dysk twardy coś sobie z tym robi, a to nie ma nic > wspólnego ze szyfrowanymi danymi. nie do końca, to ty a raczej twoja aplikacja tworzy ten dysk!!!. mówimy w końcu o tak zwanych dyskach wirtualnych. więc to aplikacja(w tym wypadku driver) jest odpowiedzialny za szyfrowanie i zapis. > > Jeśli poprawianie miałoby polegać na zmianie algorytmów i ilości > iteracji, to _nic_ nie poprawiliście. Oj "poprawiono" dużo więcej, jak już będzie po testach to rzucę pełną specyfikację. > Właśnie widzę, i stąd 256 bitów IV, z których tylko połowa jest > nieprzewidywalna. Zaczynam wątpić czy nie masz problemów z czytaniem ze zrozumieniem. Jeszcze raz: iv jest składany z nr sektora(też md5) i md5 klucza głównego, który to klucz jest pseudolosowy. Nr sektora jest podstawą szyfrowanie dla __WSZSYKICH__ systemów dyskowych, bo nie chcemy by sektor 1 i 2 wyglądał tak samo dla takiego samego teksu jawnego. Klucz główny jest dodatkowym zabezpieczeniem indywidualizującym instalację. Z tych pytań/wniosków widać że nigdy nie tworzyłeś nic podobnego. Zaprzecz jeżeli się mylę. -- Marcin Gabryszewski G DATA Software www.gdata.pl address:

user: "Stachu 'Dozzie' K."

On 29.05.2006, Marcin Gabryszewski wrote: > Stachu 'Dozzie' K. napisał(a): >> Seed? Znaczy "seed, z którego będzie zrobiony klucz"? I to według ciebie >> nie jest "security"? > Aj, nie czytałeś dokładnie. Istnieją dwa klucze!!! > jeden to MK (masterkey 256bitów i jest to klucz dla algorytmu, do > wygenerowania niego są wykorzystywane ruchy myszą i klawisze) > drugi to klucz główny(pseudolosowy) generowany przy starcie aplikacji > używany m.in. jako jedna ze składowych do iv dla algorytmu. > > > Poza tym do tej pory nie podałeś żadnego sensownego > > ataku na OTP z MD5. > a to ciekawe??? a próbowałeś powtórzyć atak, nie?? To zrób to. Później > pogadamy. Bo przy moim wyniku 3/10000 otp nie ma sensu. ROTFL. Ty weź idź się doucz trochę o kryptografii. Twój atak, pomijając małą praktyczność, _w ogóle_ nie ruszał MD5. >> Niby dlaczego? Przecież przekłamany jest tylko _jeden bit_ tekstu >> jawnego, a z opisu, który przedstawiłeś, nie widać ani śladu czegoś, co >> mogłoby rozsypać zawartość. No chyba że nie rozumiesz, co to jest >> "initial vector" w trybie CBC. > A tak w ogóle to może byś sie zdecydował czy jeden bit w tekście > jawnym(co rozumiem jeden bit w sektorze do zaszyfrowania, czyli > najnormalniejszy atak tekstem jawnym) czy w kluczu głównym. Jeden bit w tym ustrojstwie, które jest brane do IV, cytuję: | 5) bloki sektora szyfrowane w trybie cbc. gdzie IV to xor klucza | głównego i sktót(md5) numeru sektora. Czyli jeden bit w tekście jawnym. > 1)Jeżeli zmienię jeden bit w kluczu głównym(nie MK) to md5 z tego da mi > całkowicie inny wynik, czyli cały iv będzie inny!!! czyli pierwszy jak i > kolejne bloki w sektorze także. > 2)Jeżeli zmienię jeden bit w MK to w ogóle rozmowa nie ma sensu chyba że > znasz atak na aes czy twofish. > 3) Co do tekstu jawnego to zależy który bit zmienisz, jak ostatni to > ostatni blok w sektorze zostanie uszkodzony(inny kryptogram 16 bajtów). > Jeżeli pierwszy to cały sektor wyleci w kosmos. ROTFL. Proponuję poczytać o własnościach trybu CBC. I ty próbujesz wmówić, że nie kompromitujesz się swoją wiedzą kryptograficzną. >> To po co wspominasz o sektorze _dyskowym_? Przecież to byt zupełnie >> niezależny od tego, _co_ i _jak_ szyfrujemy. > Nie masz racji. Jest to bardzo ważna dana. Bo jeżeli sektor(512bajów) > idzie w trybie cbc Terminologia się kłania. Mówiłeś, że sektor to fragment, który zapisuje dysk twardy. O "łańcuchach" z CBC nic nie wspomniałeś. > to znaczy że kryptogram jest wynikiem 32( 32*16 = > 512) szyfrowań np aes w trybie cbc. więc całkowity obraz zaszyfrowanego > dysku składa się z 32 bloków po 16 bajtów które układają sie w > niezależne bloki po 512 bajtów. O właśnie, teraz mówisz do rzeczy. >> Właśnie widzę, i stąd 256 bitów IV, z których tylko połowa jest >> nieprzewidywalna. > Zaczynam wątpić czy nie masz problemów z czytaniem ze zrozumieniem. > Jeszcze raz: iv jest składany z nr sektora(też md5) i md5 klucza > głównego, który to klucz jest pseudolosowy. Poczytaj sobie jeszcze o kryptografii, bo widać, że ktoś ci kiedyś coś opowiadał, ale nie za dużo pamiętasz. A tymczasem wskazówka: jeśli druga połowa bloku to skrót MD5 pierwszej połowy, to ile bitów musi zgadnąć atakujący? > Nr sektora jest podstawą szyfrowanie dla __WSZSYKICH__ systemów > dyskowych, bo nie chcemy by sektor 1 i 2 wyglądał tak samo dla takiego > samego teksu jawnego. I uważasz, że nie może istnieć system szyfrowania dysku, który nie używa numerów "łańcucha"? > Z tych pytań/wniosków widać że nigdy nie tworzyłeś nic podobnego. > Zaprzecz jeżeli się mylę. Mylisz się. Nie po raz pierwszy zresztą. -- Feel free to correct my English Stanislaw Klekot

user: Marcin Gabryszewski

Stachu 'Dozzie' K. napisał(a): > ROTFL. Ty weź idź się doucz trochę o kryptografii. Twój atak, pomijając > małą praktyczność, _w ogóle_ nie ruszał MD5. czytaj ze zrozumieniem !!!! Ja nie atakowałem MD5, ja atakowałem otp a dokładniej skrót 64bitowy dla md5. Kurde ile razy to jeszcze będę musiał powtórzyć ??? W swoim ataku nawet nie wspominam o słabości md5!!! ct "Stachu "Twoje" otp złamałem jakiś czas temu i to nawet nie przez słabość md5 czy sha1 tylko totalnej głupoty "funkcji skrótu" stosowanej do uproszczenia oryginalnego sktótu do 64bitów." > Jeden bit w tym ustrojstwie, które jest brane do IV, cytuję: > | 5) bloki sektora szyfrowane w trybie cbc. gdzie IV to xor klucza > | głównego i sktót(md5) numeru sektora. > Czyli jeden bit w tekście jawnym. mój błąd w przytaczaniu specyfikacji. Zarówno klucz główny jak i numer sektora dysku to skróty md5. A dokładniej pierwsze 128 bitów to md5(główny)^md5(numer sektora), następne 128 to md5 tego wyniku > > ROTFL. Proponuję poczytać o własnościach trybu CBC. I ty próbujesz > wmówić, że nie kompromitujesz się swoją wiedzą kryptograficzną. Gdzie się mijam z prawdą. To że jeżeli zmienię iv to kryptogram ma inną wartość ?? > > Poczytaj sobie jeszcze o kryptografii, bo widać, że ktoś ci kiedyś coś > opowiadał, ale nie za dużo pamiętasz. Fakt było to dawno ponad 10 lat temu na studiach. A tymczasem wskazówka: jeśli druga > połowa bloku to skrót MD5 pierwszej połowy, to ile bitów musi zgadnąć > atakujący? Czy znasz problem krótkiego hasła. Nie?? to poczytaj. Tutaj widzę twoją niekonsekwencję: u mnie się czepiasz 128 bitów a sam używasz otp gdzie ich jest "tylko" 64. Znajdź najpierw te 128. Poza tym to tylko jest jeden z kluczy, zostaje jeszcze MK(czyli klucz szyfrujący) o długości 256 bitów który musisz trafisz ot tak. Życzę szczęścia. > I uważasz, że nie może istnieć system szyfrowania dysku, który nie używa > numerów "łańcucha"? Oczywiście że może, ale nie znam takiego. Wszystkie wymienione wcześniej(securedoc, ...) tego używają. Loop-aes także. > >> Z tych pytań/wniosków widać że nigdy nie tworzyłeś nic podobnego. >> Zaprzecz jeżeli się mylę. > > Mylisz się. Nie po raz pierwszy zresztą. > To podaj projekt w którym uczestniczyłeś gdzie używane jest szyfrowanie dyskowe. Chętnie się z nim zapoznam, myślę że inni userzy także. -- Marcin Gabryszewski G DATA Software www.gdata.pl address: