Algorytm - kombinacje

Cześć.
Pisze aplikację, do której będzie trzeba się zalogować. Hasło zaś musi być trzymane na komputerze w osobnym pliku. Siłą rzeczy hasło musi być zaszyfrowane w jakiejś postaci.

Wymyśliłem algorytm, który tworzy 32-literowy ciąg znakowy z hasha danego hasła. Czyli:
Hasło -> hash -> 32-literowy ciąg

gdzie hash != 32-literowego ciągu, jednak posiada te same litery co ten hash i ich liczba również jest taka sama.

Krótko mówiąc aby złamać hasło potrzeba stworzyć kombinacje dla 32 znaków. Oczywiście jeśli hash jest w postaci : "aaaaa...a" to trudno tu mówić o zabezpieczeniu, ale taka sytuacja mieć miejsca nie będzie (ani żadna inna podobnie absurdalna).

Powiedzmy, że ciąg to: "00001122467788899aabbbbbbcccccef".
Ile czasu trzeba by poświęcić na złamanie tego czegoś? Pytam, gdyż program, który piszę nie ma być kryptograficznym Bogiem, a jedynie zabezpieczyć w sposób w miarę sensowny dane użytkownika, tak aby nikt nie miał do nich dostępu po fizycznym dostępie do komputera.

czyli ten 32-literowy ciąg jest losową permutacją hasha. nie rozumiem jak by to miało działać. czy permutacja jest dla każdego hasła taka sama? jeśli nie, to musisz mieć jakiś algorytm generujący tą permutacje tak, aby aby dla danego hasła zawsze była taka sama. jedyny sposób, aby to miało jakiś sens, to ten algorytm musi być jednostronny - znając go (np. przez dekompilacje programu) i permutacje nie można odtworzyć hasha hasła. czyli de facto robisz hash z hasha. szczerze, nie rozumiem po co się w to bawić... zwyczajny hash z solą powinien w zupełności wystarczyć - skoro systemy linux tak trzymają hasła ;p

Algorytm działa jak należy. Nie jest on zbyt skomplikowany, ale jednak nieco moich pomysłów w to włożyłem po to aby gotowych narzędzi do deszyfracji nie można było znaleźć.
O algorytm proszę się nie martwić, mnie bardziej ciekawi ile by zajęło przeciętnemu komputerowi stworzenie permutacji 32 znakowej. gdzie algorytm już na wstępie udostępnia potrzebne znaki. Potem jedynie jeszcze trzeba dowiedzieć się co oznacza hash i mamy hasło :)

Po prostu ciekawi mnie prędkość tworzenia 32-znakowej permutacji.

Pierwsza zasada kryptografii - don't invent it yourself.

W przypadku implementowania własnych algorytmów związanych z kryptografią należy wykonać rzut kostką K1, by sprawdzić czy za pierwszym razem coś spieprzyłeś...
Użyj jakiś gotowych i sprawdzonych funkcji skrótu, polecam blowfish. Customowe rozwiązania często mają gdzieś straszne wpadki, popularne funkcje skrótu już zostały dokładniej zbadane.

wszystkich permutacji jest 32! - to powinien wiedzieć uczeń z gimnazjum... chodzi mi to, że jeżeli algorytm generujący permutacje jest słaby (a skoro pytasz się o takie rzeczy pewnie jest słaby), to niedobry haker może łatwo tą permutację odwrócić i uzyskać hash z hasła.

Pierwsza zasada kryptografii - don't invent it yourself.

W życiu o takiej głupocie nie słyszałem. Przecież ktoś zawsze musi być tym pierwszym i wymyślić algorytm. W ten czy inny sposób, z gorszym lub lepszym skutkiem.
Brak nowych pomysłów = brak rozwoju.

Poza tym na świecie systematycznie powstają własnie nowe algorytmy z powodu narastających potrzeb coraz lepszej ochrony danych.

krypto-graf napisał(a):

Pierwsza zasada kryptografii - don't invent it yourself.

W życiu o takiej głupocie nie słyszałem. Przecież ktoś zawsze musi być tym pierwszym i wymyślić algorytm. W ten czy inny sposób, z gorszym lub lepszym skutkiem.
Brak nowych pomysłów = brak rozwoju.

Poza tym na świecie systematycznie powstają własnie nowe algorytmy z powodu narastających potrzeb coraz lepszej ochrony danych.

Ale są badane przez grupy naukowców obeznanych z tematem i mających dużo wolnego czasu na takie pierdoły. Obecnie wszystkie powszechnie stosowane rzeczy są cholernie skomplikowane. Wynajdując nową funkcję skrótu w momencie kiedy jest ich od ciula i trochę (znacznie lepiej zbadanych niż Twoja inwencja kiedykolwiek będzie) to szukanie sobie wyłącznie guza na głowę.

Ale są badane przez grupy naukowców obeznanych z tematem i mających dużo wolnego czasu na takie pierdoły. Obecnie wszystkie powszechnie stosowane rzeczy są cholernie skomplikowane. Wynajdując nową funkcję skrótu w momencie kiedy jest ich od ciula i trochę (znacznie lepiej zbadanych niż Twoja inwencja kiedykolwiek będzie) to szukanie sobie wyłącznie guza na głowę.

Masz rację, ale w takim razie proszę nie pisać jakichś bzdur o prawach i zasadach, które nigdy nie miały miejsca.
Co do innych rad to bardzo dziękuję z pewnością mi się przydadzą.

Chciałeś odpowiedź na swoje pytanie: zajęłoby to czas liczony w minutach. Czemu? Bo złamałeś zasadę:
http://pl.wikipedia.org/wiki/Zasada_Kerckhoffsa
Opierasz swój magiczny algorytm na tym że nikt nie zna twojego algorytmu a to jest błąd. Jeśli szyfrujesz tak jak powiedziałeś to znaczy że w kodzie masz gdzieś zapisane jak permutujesz klucz (nie ma znaczenia czy to jakoś wyliczasz czy masz w kodzie zahardkodowane). W efekcie można twój kod deasemblować i sprawdzić jakie operacje wykonujesz na kluczu i je zwyczajnie odwrócić. Dziecięca igraszka.
Zamiast zgrywać mądralę może jednak posłuchasz kolegów i skorzystasz z już gotowych algorytmów...

przy okazji:

Przecież ktoś zawsze musi być tym pierwszym i wymyślić algorytm.

masz rację, tylko że na te aktualnie używane algorytmy "wpadły" dziesiątki najlepszych matematyków świata opłacanych za grubą kasę przez amerykańskie NSA...

Chciałeś odpowiedź na swoje pytanie: zajęłoby to czas liczony w minutach. Czemu? Bo złamałeś zasadę:
http://pl.wikipedia.org/wiki/Zasada_Kerckhoffsa
Opierasz swój magiczny algorytm na tym że nikt nie zna twojego algorytmu a to jest błąd. Jeśli szyfrujesz tak jak powiedziałeś to znaczy że w kodzie masz gdzieś zapisane jak permutujesz klucz (nie ma znaczenia czy to jakoś wyliczasz czy masz w kodzie zahardkodowane). W efekcie można twój kod deasemblować i sprawdzić jakie operacje wykonujesz na kluczu i je zwyczajnie odwrócić. Dziecięca igraszka.
Zamiast zgrywać mądralę może jednak posłuchasz kolegów i skorzystasz z już gotowych algorytmów...

No to niespodzianka, bo nie masz racji. Podany wyżej hash jest stworzony za pomocą MD5 (od początku z niego korzystałem) plus w odpowiednim momencie posortowany (w odpowiednim momencie, gdyż wiadomo, iż sortować nie można w czasie autoryzacji). Ergo - zasada nie złamana.

No to niespodzianka, bo nie masz racji. Podany wyżej hash jest stworzony za pomocą MD5 (od początku z niego korzystałem) plus w odpowiednim momencie posortowany (w odpowiednim momencie, gdyż wiadomo, iż sortować nie można w czasie autoryzacji).

Dlaczego po prostu nie użyjesz jakiegoś SHA-2 od razu, zamiast kombinować z MD5, sortowaniem, permutowaniem, wycinaniem i co tam jeszcze? Będzie prościej dla Ciebie i bezpieczniej dla użytkowników...

@krypto-graf a to czemu? Skoro użyłeś niezbyt bezpiecznego md5 i coś potem z nim zrobiłeś? Łamanie twojego hasła w takim razie sprowadzi sie po prostu do złamania samego md5 (no bo jak juz ci napisałem, te twoje operacje są to zlamania w kilka chwil). A łamać md5 się da, a jeśli nie solisz tych haseł, to znów kilka chwil łamania jak ma się pod reką odpowiednie rainbow tables...

@msm SHA-2 nie jest jakoś specjalnie bezpieczniejsze do przechowywania haseł niż md5. Haseł nie łamie się przez znalezienie pre-image (na md5 złożoność około 2^100, czyli niemożliwe), tylko przez sprawdzanie różnych haseł (8 znaków z [a-zA-Z0-9] daje 47 bitów).

Nawet soląc tego hasha, 8 znakowe hasło nie jest bezpieczne, ponieważ zwykła karta graficzna jest w stanie liczyć 10^9 hashy na sekundę. Standardowym sposobem przechowywania haseł jest używanie PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2), powinna być niego implementacja w każdej pożądnej bibliotece kryptograficznej. Używanie do haseł szybkich hashy jest pomysłem domorosłych webdeveloperów, nie spotkałem się, żeby jakikolwiek pożądny program desktopowy używał czegoś takiego.

@ "kryptograf" Ten schemat nie ma szans być bezpiecznym, ponieważ atakujący może po prostu zmienić hash w tym pliku tekstowym, na taki, w którym jego hasło przechodzi. Podejrzenie zasady działania twojego szyfrowania w Idzie nie jest dużym problemem, żeby to było bezpieczne musisz szyfrować swój program za pomocą tego hasła.

W kwestii hasła. Napisałem algorytm szyfrujący to samo hasło za każdym razem inaczej. Innymi słowy, przykładowo, jeśli Twoje hasło wpisywane z klawiatury ='mojehasło' to po zaszyfrowaniu może wyglądać raz tak='olF▒mjĹt▓˘s' a innym razem to samo ('mojehasło') może wyglądać tak='ęČdkjYuH¬ÍKs'. W samym haśle zaszyfrowany jest też zmieniający się klucz, który jest częścią algorytmu do jego odszyfrowania. Prawdopodobieństwo powtórzenia się zaszyfrowanego ciągu dla tego samego hasła 'mojehasło' wynosi 1:86400 a to oznacza, że jeśli każdego dnia będziesz zmieniał hasło z 'mojehasło' na 'mojehasło' (czyli takie samo), to prawdopodobnie raz na 86400 zmian hasła wynikowy szyfr może się powtórzyć 1 raz.