Witam !
Chciałbym spytać o opinię. Na grupie news:pl.comp.programming przedstawiłem pewne
rozwiązanie
związane z autoryzacją i przesyłaniem danych o haśle użytkownika na serwer przez,
powiedzmy,
chronione, ale nie absolutnie, łącze.
Watek:
http://groups.google.com/groups?dq=&...l.comp.program
ming&selm=bt4s9t%24l41%241%40inews.gazeta.pl

W skrócie: postanowiłem, by zamast przesyłać na serwer zakodowane hasło (jego skrót)
kanałem szyfrowanym asymetrycznie
(dużo zachodu), będę po prostu tworzył (po stronie klienta) na podstawie hasła parę
kluczy (w sposób jednoznaczny: to samo hasło
zawsze generuje takie same klucze) i przesyłał na serwer klucz publiczny (zamiast
hasła).

Dzięki temu klient uzyskuje zdolność do tego, by na wszystkim co wysyła do serwera
składać swoje podpisy i w ten sposób
staje się dla serwera wiarygodny.
Obecna implementacja stosuje algorytm DSA z szyfrowaniem 1024 bitowym.

Tak więc założyłem, że w ostateczności ktoś może zdobyć klucze publiczne, ale liczę
na to,
że nie przyniesie mu to zbytniego pożytku.

Jak oceniacie ryzyko takiego rozwiązania ? Czy należy obawiać się brute-force'a,
zakładając,
że założy się w miarę duże restrykcje na hasło ? Powiedzmy 8 znaków, wymuszenie cyfr
itp.
Czyli będzie pewnie z jakieś 40 (dobrze szacuję ?) bitów różnych potencjalnych
kombinacji.
No i ten ktoś musiałby zdobyć i rozłożyć na części aplikację kliencką, by dokładnie
poznać
sposób przejścia hasło->klucz prywatny.
Generalnie ochrona ma być nastawiona głównie na wnętrze, przed administratorami
systemu,
którzy mogą klucze publiczne odczytać bezpośrednio z bazy danych. Wydaje mi się, że
umieszczenie
w bazie bezpośrednio skrótów haseł byłoby jeszcze mniej bezpieczne z tej strony.

Widzicie możliwości jakiś innych ataków ?

Filip Sielimowicz
[url down]

"Filip Sielimowicz" <sielim> wrote in
news:btbgia$2gv$1:

> W skrócie: postanowiłem, by zamast przesyłać na serwer zakodowane
> hasło (jego skrót) kanałem szyfrowanym asymetrycznie
> (dużo zachodu), będę po prostu tworzył (po stronie klienta) na
> podstawie hasła parę kluczy (w sposób jednoznaczny: to samo hasło
> zawsze generuje takie same klucze) i przesyłał na serwer klucz
> publiczny (zamiast hasła).

Ten klucz przesyłasz niekodowanym kanałem? W takim razie ktoś go
przechwytuje i używa, bez znajomości hasła (bo i po co mu ono, skoro
serwer rozpoznaje tylko po kluczu publicznym).
Popraw, jeśli się mylę.

Użytkownik "Paweł 'Róża' Różański" <rozie> napisał w wiadomości
news:u0j1
> "Filip Sielimowicz" <sielim> wrote in
> news:btbgia$2gv$1:
>
> > W skrócie: postanowiłem, by zamast przesyłać na serwer zakodowane
> > hasło (jego skrót) kanałem szyfrowanym asymetrycznie
> > (dużo zachodu), będę po prostu tworzył (po stronie klienta) na
> > podstawie hasła parę kluczy (w sposób jednoznaczny: to samo hasło
> > zawsze generuje takie same klucze) i przesyłał na serwer klucz
> > publiczny (zamiast hasła).
>
> Ten klucz przesyłasz niekodowanym kanałem? W takim razie ktoś go
> przechwytuje i używa, bez znajomości hasła (bo i po co mu ono, skoro
> serwer rozpoznaje tylko po kluczu publicznym).
> Popraw, jeśli się mylę.

Nie, nie ... Serwer używa klucza publicznego do weryfikacji podpisu elektronicznego.
Natomiast żeby złożyć taki podpis trzeba mieć klucz prywatny, a żeby go uzyskać,
trzeba znać hasło.
Mając więc klucz publiczny nie możesz składać podpisów (a więc podszywać się pod
kogoś), możesz jedynie sprawdzać autentyczność podpisów tego, kto Ci ten klucz
wcześniej przesłał.

Czyli przykładowy proces autoryzacji użytkownika wygląda tak: serwer
wysyła użytkownikowi dowolną, powiedzmy losową wiadomość i każe
mu ją podpisać (podpis jest zależny od treści wiadomości, inaczej niż
w rzeczywistych papierowych dokumentach, nie tylko od indywidualnych
cech podpisującego).
Użytkownik, jeśli zna hasło, to wygeneruje prawidłowy klucz prywatny i
podpisze tę wiadomość. Odeśle tak podpisaną do serwera, a serwer
mając klucz publiczny bez trudu sprawdzi autentyczność podpisu.

Poważny problem jaki ja tutaj widzę jest tylko jeden: mając klucz publiczny
i wiedząc, że jest on sprzężony z hasłem, można się pokusić o brutalny
atak sprawdzania wszystkich możliwości, bo rzeczywiste hasła są
stosunkowo mało na to odporne. Trzeba tylko znać dokładny algorytm
generowania pary kluczy na podstawie hasła, który jest zaimplementowany
w aplikacji klienckiej.

Filip Sielimowicz
[url down]

"Filip Sielimowicz" <sielim> wrote in
news:bte8sj$l9a$1:

>> Ten klucz przesyłasz niekodowanym kanałem? W takim razie ktoś go
>> przechwytuje i używa, bez znajomości hasła (bo i po co mu ono,
>> skoro serwer rozpoznaje tylko po kluczu publicznym).
>> Popraw, jeśli się mylę.
> Nie, nie ... Serwer używa klucza publicznego do weryfikacji
> podpisu elektronicznego. Natomiast żeby złożyć taki podpis trzeba
> mieć klucz prywatny, a żeby go uzyskać, trzeba znać hasło.
> Mając więc klucz publiczny nie możesz składać podpisów (a więc
> podszywać się pod kogoś), możesz jedynie sprawdzać autentyczność
> podpisów tego, kto Ci ten klucz wcześniej przesłał.

OK, teraz rozumiem.

[ciach]

> Użytkownik, jeśli zna hasło, to wygeneruje prawidłowy klucz
> prywatny i podpisze tę wiadomość. Odeśle tak podpisaną do serwera,
> a serwer mając klucz publiczny bez trudu sprawdzi autentyczność
> podpisu.
>
> Poważny problem jaki ja tutaj widzę jest tylko jeden: mając klucz
> publiczny i wiedząc, że jest on sprzężony z hasłem, można się
> pokusić o brutalny atak sprawdzania wszystkich możliwości, bo
> rzeczywiste hasła są stosunkowo mało na to odporne. Trzeba tylko
> znać dokładny algorytm generowania pary kluczy na podstawie hasła,
> który jest zaimplementowany w aplikacji klienckiej.

Wydaje mi się, że w stosunku do rozwiązania typu GPG zalet jest
niewiele - chyba tylko to, że nie trzeba mieć przy sobie klucza
prywatnego, bo jest on generowany z hasła, co umożliwia korzystanie z
niego 'zawsze'. A cudzysłów stąd, że na maszynie, na której generujesz
klucz publiczny, musisz mieć klienta. Jeśli będzie on OS, to przy
założeniu możliwości przechwytywania klucza i wiadomości (zdaje się, że
to zakładasz, bo 'chronione, ale nie absolutnie' oznacza niechronione),
przy słabym haśle, odgadnięcie hasła zajmie 'moment'. BTW czemu hasło
asymetryczne? W końcu serwer i tak nic szyfrowanego nie wysyła (jeśli
dobrze rozumiem).

"Filip Sielimowicz" <sielim> writes:

> Poważny problem jaki ja tutaj widzę jest tylko jeden: mając klucz publiczny
> i wiedząc, że jest on sprzężony z hasłem, można się pokusić o brutalny
> atak sprawdzania wszystkich możliwości, bo rzeczywiste hasła są
> stosunkowo mało na to odporne.

Chyba "majac (zaszyfrowany) klucz prywatny"? Bo do czego to haslo ma
sluzyc jesli nie do rozszyfrowania klucza prywatnego?

> Wydaje mi się, że w stosunku do rozwiązania typu GPG zalet jest
> niewiele - chyba tylko to, że nie trzeba mieć przy sobie klucza
> prywatnego, bo jest on generowany z hasła, co umożliwia korzystanie z
> niego 'zawsze'. A cudzysłów stąd, że na maszynie, na której generujesz
> klucz publiczny, musisz mieć klienta. Jeśli będzie on OS, to przy
> założeniu możliwości przechwytywania klucza i wiadomości (zdaje się, że
> to zakładasz, bo 'chronione, ale nie absolutnie' oznacza niechronione),
> przy słabym haśle, odgadnięcie hasła zajmie 'moment'.
Co to znaczy "klient będzie OS" ?
Generalnie właśnie to mnie intryguje: ile czasu zajmie odgadniecie
hasła, które, powiedzmy, nie będzie aż tak słabe, tylko powiedzmy
8 losowych znaków. Ewentualny atak będzie mozliwy jedynie przy dokładnym
rozpracowaniu procedur klienta, które implementują przejście
hasło->para kluczy.

W tym momencie bardzo by się przydała jakaś nieodwracalna funkcja
skrótu, która wymaga sporego nakładu obliczeniowego, powiedzmy,
przy dzisiejszych procesorach 1 GHz wymaga 100-1000 ms na obliczenie
skrótu z hasła 8 literowego. Byłaby to dość skuteczna zapora przed
atakami "na pałę" (brute force to się nazywa ?).
Zapytam o to w oddzielnym wątku.


> BTW czemu hasło
> asymetryczne? W końcu serwer i tak nic szyfrowanego nie wysyła (jeśli
> dobrze rozumiem).

Nie, nie ma potrzeby szyfrowania. Zresztą szyfrowanie można wprowadzić później,
dla całego kanału transmisyjnego. Na razie chodzi tylko o to, by serwer mogł
zawsze zweryfikować nadawcę wszelkich informacji, w szczególności kiedy ten
nadawca (klient) chce zmienić hasło na inne.

Filip Sielimowicz wrote:
> Generalnie właśnie to mnie intryguje: ile czasu zajmie odgadniecie
> hasła, które, powiedzmy, nie będzie aż tak słabe, tylko powiedzmy 8
> losowych znaków. Ewentualny atak będzie mozliwy jedynie przy
> dokładnym rozpracowaniu procedur klienta, które implementują
> przejście hasło->para kluczy.

Ten problem był poruszany podczas dyskusji nad (przyszłym) standardem
IEEE 802.11i. Zobacz, jak to jest rozwiązane w tym standardzie (a także
w standardzie WPA), do tego przeczytaj
http://wifinetnews.com/archives/002452.html.

> Chyba "majac (zaszyfrowany) klucz prywatny"? Bo do czego to haslo ma
> sluzyc jesli nie do rozszyfrowania klucza prywatnego?

Nie do końca... :)

Możemy w uproszczeniu uznać, że hasło i klucz prywatny
są (i powinny być) tak samo chronione. Ich ochrona jest warunkiem
koniecznym do tego, by całość miała sens.

Jest tak jak z podpisami elektronicznymi. Algorytmem DSA
jest generowana para kluczy, prywatny i publiczny.
Klucz prywatny służy do składania podpisów, klucz
publiczny do ich weryfikacji (tylko i wyłącznie).
Klucz publiczny ma serwer, by zawsze mógł zweryfikować,
kto z nim gada, czyli serwer wymaga od klienta, by podpisywał
to, co mu przekazuje. Serwerowi do niczego nie jest
potrzebna znajomość ani hasła, ani klucza prywatnego,
wystarczy mu klucz publiczny. Algorytm DSA zapewnia, by
uzyskanie klucza prywatnego z klucza publicznego było
niemożliwe (czyt: trudne obliczeniowo).

Ja wprowadziłem dodatkowy element: nie chcę, by
klucz prywatny był przechowywany po stronie klienta.
Chcę, by użytkownik miał go w głowie. Oczywiście
pamiętanie klucza prywatnego jest nonsensem,
więc chcę, by użytkownik pamiętał jedynie hasło, a na jego
podstawie, w sposób jednoznaczny, była generowana para
kluczy. Tak więc ilekroć użytkownik ma coś podpisać to
podaje hasło, na jego podstawie jest generowana para kluczy
i klucz prywatny jest używany do składania podpisu (klucz
publiczny się tu nie przydaje). Jeśli użytkownik nie zna hasła,
to wygenerowany klucz prywatny źle podpisze wiadomość
i serwer od razu to zweryfikuje. KPW ?

Problem powstaje z tego powodu, że o ile odzyskanie
klucza prywatnego z klucza publicznego jest odporne na
atak brutalny, o tyle hasło użytkownika już nie.
Klucz publiczny można tu bowiem traktować jako pewien
skrót hasła użytkownika. Mając ten klucz można się pokusić
o brutalny atak poprzez podstawianie wszelkich kombinacji
haseł. Warunek: trzeba znać algorytm przejścia hasło->para
kluczy. Tyle, że to nie jest problem (powiedzmy ...), bo
algorytm jest zaszyty w aplikacji klienta.

W związku z tym planuję, by skomplikować ten algorytm, nie
w sensie implementacyjnym, ale w sensie obliczeniowym.
Czyli chcę, by generowanie pary kluczy na podstawie hasła
było względnie złożone obliczeniowo (i jednocześnie
nieodwracalne). Względnie, tzn. by dzisiejsze komputery
użytkownika (powiedzmy 1 GHz) liczyły to w czasie rzędu
jednej sekundy.
Powoduje to oczywiście wydłużenie o ten czas procedury składania
podpisu (mając podane hasło), ale to u mnie nie jest
problem. Za to ewentualny brutalny atak przy użyciu tej procedury
nie będzie miał sensu.

Poszukuję więc obecnie funkcji skrótu (może nie jest to najlepsze
określenie), poszukuję funkcji, która na podstawie hasła wygeneruje
mi złożony klucz i będzie to trwało trochę czasu (klucz ten będzie potem
wejściem do algorytmu DSA).
Myślałem o użyciu zwykłaego md5 wywoływanego w pętli, o odpowiedniej
ilości bitów. Mam jednak wątpliwości (mgliście potwierdzone), czy
md5 wywoływany rekurencyjnie na samym sobie zachowuje swoje pierwotne
cechy, tzn. czy np. istnieje takie x, że md5(x)=x, albo czy np. nie zapętla
się w stosunkowo małych cyklach powtórzeń tych samych wartości.
To by bardzo istotnie osłabiło skuteczność całej metody.

Filip Sielimowicz
[url down]

"Filip Sielimowicz" <sielim> wrote in
news:btgvrd$jqd$1:

> Co to znaczy "klient będzie OS" ?

Open source. Sorry za skrót, na pco.advocacy jest w powszechnym użyciu
i się zapomniałem. Jeśli jest OS, to z jednej strony więcej ludzi go
użyje (niektórzy nie użyją programu bez dostępu do źródeł), z drugiej
wszystkie dziury ma na wierzchu. Mimo wszystko, jeśli ma to być coś
poważniejszego niż własne zastosowania, to polecałbym OS.

> Generalnie właśnie to mnie intryguje: ile czasu zajmie odgadniecie
> hasła, które, powiedzmy, nie będzie aż tak słabe, tylko powiedzmy
> 8 losowych znaków.

Bardzo zależy. Np. w John the Ripper jest:
<quote>
Unlike other crackers, John doesn't use a crypt(3)-style routine.
Instead, it has its own highly optimized modules for different
ciphertext formats and architectures.
<quote>
To, co u Ciebie może być dość wolne, może dać się zapisać w szybszej
wersji.

> Ewentualny atak będzie mozliwy jedynie przy
> dokładnym rozpracowaniu procedur klienta, które implementują
> przejście hasło->para kluczy.

Czyli rozumiem, że źródła nie udostępniasz. Jest to jakieś
utrudnienie, przynajmniej do momentu, kiedy ktoś 'dorwie' Twój plik
wykonywalny. Bo prawda jest taka, że jeśli komuś zależy, to
zdekompiluje sobie...

> W tym momencie bardzo by się przydała jakaś nieodwracalna funkcja
> skrótu, która wymaga sporego nakładu obliczeniowego, powiedzmy,
> przy dzisiejszych procesorach 1 GHz wymaga 100-1000 ms na
> obliczenie skrótu z hasła 8 literowego. Byłaby to dość skuteczna
> zapora przed atakami "na pałę" (brute force to się nazywa ?).

John the Ripper nie atakuje całkiem 'na pałę'. Pewne kombinacje
sprawdza wcześniej niż inne. Można ustalić, które.
Ja w taką funkcję nie bardzo wierzę, szczerze mówiąc, przynajmniej nie
'domowej roboty' (z kolei stosując gotowe rozwiązania praktycznie
udostępniasz kod klienta). Zawsze może trafić się zależność, że
wykonujesz 1001 razy operację typu 'zwiększ wartość bajtu o 1' czy NOT,
a ktoś to zauważy i zapisze w łamaczu od razu jako zwiększanie o 1001
czy jedno NOT (tylko przykład).

> Nie, nie ma potrzeby szyfrowania. Zresztą szyfrowanie można
> wprowadzić później, dla całego kanału transmisyjnego. Na razie
> chodzi tylko o to, by serwer mogł zawsze zweryfikować nadawcę
> wszelkich informacji, w szczególności kiedy ten nadawca (klient)
> chce zmienić hasło na inne.

Dobrze, a czemu nie skorzystać po prostu z SSH? Wydaje mi się, że daje
to dokładnie to samo (identyfikacja przy logowaniu), plus to, że cała
transmisja jest szyfrowana (a nie tylko podpisywanie danych) i limity
na ilości prób łamania hasła (limit prób logowania). Bezpieczeństwo
stacji roboczej (podajesz hasło z klawiatury) i serwera (chyba
oczywiste, chociaż patrz ps2) i tak zakładasz...

ps. Napisz po co Ci to dokładnie, czy do użytku prywatnego, czy chcesz
udostępniać.
ps2. Pisałeś coś o ochronie przed administratorami. Nie bardzo w to
wierzę, bo przecież klucz publiczny trzymasz i tak na serwerze...

"Filip Sielimowicz" <sielim> writes:

> Ja wprowadziłem dodatkowy element: nie chcę, by
> klucz prywatny był przechowywany po stronie klienta.
> Chcę, by użytkownik miał go w głowie. Oczywiście
> pamiętanie klucza prywatnego jest nonsensem,
> więc chcę, by użytkownik pamiętał jedynie hasło, a na jego
> podstawie, w sposób jednoznaczny, była generowana para
> kluczy.

To nie jest korzystne wyjscie. Chyba ze to bedzie tak, ze klucz prywatny
bedzie przechowywany na serwerze w postaci zaszyfrowanej, i nastepnie
bedzie rozszyfrowywany haslem usera na koncowce. Wtedy, zaleznie od
algorytmu szyfrowania, moze to byc sensowne.
Oczywiscie koncowka musi spelniac odpowiednie wymagania. Algorytm
szyfrowania i haslo musza byc takze odpowiednie.

> Tak więc ilekroć użytkownik ma coś podpisać to
> podaje hasło, na jego podstawie jest generowana para kluczy
> i klucz prywatny jest używany do składania podpisu (klucz
> publiczny się tu nie przydaje). Jeśli użytkownik nie zna hasła,
> to wygenerowany klucz prywatny źle podpisze wiadomość
> i serwer od razu to zweryfikuje. KPW ?

Ale ile bitow losowych bedzie mial ten klucz?

> Warunek: trzeba znać algorytm przejścia hasło->para
> kluczy. Tyle, że to nie jest problem (powiedzmy ...), bo
> algorytm jest zaszyty w aplikacji klienta.

Innymi slowy, dostep do algorytmu ma m.in. kazdy, kto ma dostep do
aplikacji klienta. "M.in.", tzn. nie tylko te osoby.

> Myślałem o użyciu zwykłaego md5 wywoływanego w pętli, o odpowiedniej
> ilości bitów. Mam jednak wątpliwości (mgliście potwierdzone), czy
> md5 wywoływany rekurencyjnie na samym sobie zachowuje swoje pierwotne
> cechy,

Tak, ale z punktu widzenia teorii to nie sa korzystne pomysly: ilosci
entropii to nie zwieksza.

Polecam jakas ogolna ksiazke o kryptografii, np. Handbook of Applied
Crypto i/lub Schneiera.

On Thu, 08 Jan 2004 15:17:27 +0100, Krzysztof Halasa <khc>
wrote:

>"Filip Sielimowicz" <sielim> writes:
>
>> Ja wprowadziłem dodatkowy element: nie chcę, by
>> klucz prywatny był przechowywany po stronie klienta.
>> Chcę, by użytkownik miał go w głowie. Oczywiście
>> pamiętanie klucza prywatnego jest nonsensem,
>> więc chcę, by użytkownik pamiętał jedynie hasło, a na jego
>> podstawie, w sposób jednoznaczny, była generowana para
>> kluczy.
>
>To nie jest korzystne wyjscie. Chyba ze to bedzie tak, ze klucz prywatny
>bedzie przechowywany na serwerze w postaci zaszyfrowanej, i nastepnie
>bedzie rozszyfrowywany haslem usera na koncowce. Wtedy, zaleznie od
>algorytmu szyfrowania, moze to byc sensowne.

Jak Ty to czytałeś? Jest dość oczywiste, że w tym rozwiązaniu klucz
prywatny *nie będzie* przechowywany. Nigdzie.


Ja natomiast mam co do całej idei inną wątpliwość - typowo przy
generowaniu klucza (np. w PGP czy GnuPG) jest wykorzystywane jakieś
źródło entropii - np. klepanie w klawiaturę czy ruszanie myszką. Tu,
jak rozumiem, właśnie ten ciąg bitów otrzymany z hasła za pomocą
funkcji skrótu ma *zastąpić* element losowy. No to pytanie, czy 128
bitów (tyle dają typowe funkcje skrótu) to nie jest za mało.

> Ja natomiast mam co do całej idei inną wątpliwość - typowo przy
> generowaniu klucza (np. w PGP czy GnuPG) jest wykorzystywane jakieś
> źródło entropii - np. klepanie w klawiaturę czy ruszanie myszką. Tu,
> jak rozumiem, właśnie ten ciąg bitów otrzymany z hasła za pomocą
> funkcji skrótu ma *zastąpić* element losowy. No to pytanie, czy 128
> bitów (tyle dają typowe funkcje skrótu) to nie jest za mało.

To się zgadza. Ale akurat ze zwiększeniem ilości bitów generowanych
przez funkcję skrótu nie ma żadnego problemu. Pierwszy lepszy przykład
wymyślony na poczekaniu:

Mamy md5 generujący skrót 128 bitów z dowolnej liczby (ciągu bitów)
Operatorem '|' oznaczę operację konkatenacji bitów, czyli z dwóch liczb
n-bitowych otrzymuję liczbę 2n-bitową.
Tworzymy funkcję pomocniczą mdc:
mdc(x)= md5(x+c1) | md5(x+c2), gdzie c1 i c2 to dowolne stałe.

Ostateczna 256 bitowa funkcja skrótu dla dowolnej liczby może teraz
wyglądać np. tak:
md5_256(x)=mdc(mdc(mdc(mdc(x))))
Nie wiem, na ile "słabszy" jest ten md5_256 od implementacji zgodnej
z orginalnym algorytmem (którego nawiasem mówiąc nie znam), która
by generowała 256 bitów, ale na pewno jest dużo silniejszy, niż 128 bitów.
Pokazuję tu tylko prostą ideę.

Problem w tym, że entropia wprowadzana przez same hasła użytkowników
już jest znacznie mniejsza niż 128 bitów (powiedzmy 8 liter po 4-5 bitów góra
każdy to jakieś 36bitów - tak to szacuję), a to trudno przeskoczyć.
Nie wiem jednak, jak w takiej sytuacji sama wiedza o słabym źródle
entropii pomaga w bardziej zaawansowanych atakach, skoro i tak,
przy dobrej funkcji skrótu, trzeba z ogromnej przestrzeni wszystkich
możliwych "losowych liczb wejściowych" wyłapywać tylko te
dopuszczalne nie inaczej, jak przez ich jawne obliczenie.
A to chcę właśnie utrudnić.

> > Tak więc ilekroć użytkownik ma coś podpisać to
> > podaje hasło, na jego podstawie jest generowana para kluczy
> > i klucz prywatny jest używany do składania podpisu (klucz
> > publiczny się tu nie przydaje). Jeśli użytkownik nie zna hasła,
> > to wygenerowany klucz prywatny źle podpisze wiadomość
> > i serwer od razu to zweryfikuje. KPW ?
>
> Ale ile bitow losowych bedzie mial ten klucz?
Przy sile kodowania ustawianej dla DSA wynoszącej 512
generowane klucze prywatne mają u mnie 160 bitów,
a klucze publiczne 520 bitów.
Dla siły kodowania DSA 1024 bity mają odpowiednio
160 bitów (prywatny bez zmian) i 1032 bity (publiczny dłuższy).

> > Warunek: trzeba znać algorytm przejścia hasło->para
> > kluczy. Tyle, że to nie jest problem (powiedzmy ...), bo
> > algorytm jest zaszyty w aplikacji klienta.
>
> Innymi slowy, dostep do algorytmu ma m.in. każdy, kto ma dostep do
> aplikacji klienta. "M.in.", tzn. nie tylko te osoby.

Tak, tak zakładam, ponieważ aplikacja kliencka jest relatywnie słabo chroniona
(setki stacji roboczych rozproszonych po całej Polsce, a więc ciężko utrzymać
nad tym pełną kontrolę.). Pod tym względem sprawa ochrony kluczy publicznych
wyglada jak przy podpisach elektronicznych: są po prostu PUBLICZNIE
ogłaszane.

> > Myślałem o użyciu zwykłaego md5 wywoływanego w pętli, o odpowiedniej
> > ilości bitów. Mam jednak wątpliwości (mgliście potwierdzone), czy
> > md5 wywoływany rekurencyjnie na samym sobie zachowuje swoje pierwotne
> > cechy,
>
> Tak, ale z punktu widzenia teorii to nie sa korzystne pomysly: ilosci
> entropii to nie zwieksza.

Nie znam dokładnie pojęć z dziedziny kryptografii, ale domyślam się, że w tym
kontekście entropię należy rozumieć jako stopień rozproszenia informacji ?
Czyli idealna funkcja skrótu daje idealną, maksymalną entropię (tylko teoretyczną).

Zgadzam się, ale moim celem nie jest zwiększenie entropii (zakładam, że już
md5 jest bliskie ideału pod tym względem i nie ma co poprawiać), ale
zwiekszenie złożoności obliczeniowej takiej funkcji. By nie dało się jej łatwo
obliczyć a próby ewentualnej optymalizacji na zasadzie cache'owania obliczanych
wartości kończyły się niepowodzeniem z powodu braku pamięci.

> Polecam jakas ogolna ksiazke o kryptografii, np. Handbook of Applied
> Crypto i/lub Schneiera.

A może jakieś wykłady na polskich uczelniach są udostępnione ?
Tak się składa, że o ile miałem trochę do czynienia z teorią złożoności
obliczeniowej, to nigdy nie dane mi było uczestniczyć w
wykładach/laborkach traktujących o wykorzystaniu tej wiedzy w
kryptografii.

Pozdrowienia !

Filip Sielimowicz
[url down]

Szymon Sokół <szymon> wrote in
news:btk98s.3vv8v33.1:

>>> Ja wprowadziłem dodatkowy element: nie chcę, by
>>> klucz prywatny był przechowywany po stronie klienta.
>>> Chcę, by użytkownik miał go w głowie. Oczywiście
>>> pamiętanie klucza prywatnego jest nonsensem,
>>> więc chcę, by użytkownik pamiętał jedynie hasło, a na jego
>>> podstawie, w sposób jednoznaczny, była generowana para
>>> kluczy.
>>To nie jest korzystne wyjscie. Chyba ze to bedzie tak, ze klucz
>>prywatny bedzie przechowywany na serwerze w postaci zaszyfrowanej,
>>i nastepnie bedzie rozszyfrowywany haslem usera na koncowce.
>>Wtedy, zaleznie od algorytmu szyfrowania, moze to byc sensowne.
> Jak Ty to czytałeś? Jest dość oczywiste, że w tym rozwiązaniu
> klucz prywatny *nie będzie* przechowywany. Nigdzie.

Przez chwilę (przynajmniej) będzie istniał na końcówce (wygenerowany z
hasła). Czyli de facto końcówka musi być (jakiś czas) bezpieczna. A jak
jest (jakiś czas) bezpieczna, to można tam mieć (w tym czasie) normalny
klucz prywatny z GPG, prawda? Znaczy nie bardzo widzę powód, czemu nie
stosować GPG (do podpisywania/szyfrowania).

> Przez chwilę (przynajmniej) będzie istniał na końcówce (wygenerowany z
> hasła). Czyli de facto końcówka musi być (jakiś czas) bezpieczna. A jak
> jest (jakiś czas) bezpieczna, to można tam mieć (w tym czasie) normalny
> klucz prywatny z GPG, prawda?
Znaczy się chodzi Ci o to, że stawiam szyfrowane połączenie, uzgadnianie
kluczy itp., a wpierw jest lokalnie generowany (za każdym razem)
klucz losowy ? OK. Ale to jest bardziej złożone implementacyjnie.

A tak dla formalności: każda końcówka operująca hasłem użytkownika
"musi być w tym czasie bezpieczna".
Ja zakładam, że w czasie rzeczywistej pracy użytkownika na końcówce
nikt mu nie zagląda bezpośrednio w pamięć komputera i procesor. Jeśli
to nie jest spełnione, to żaden system nam nie zapewni ochrony np. przed
poznaniem hasła.

Filip Sielimowicz
[url down]