Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
news:04p396tlpn7sib7ojpr3067jkm0b7n8lbh@4ax.com...
>
> ale milion mieszań wcale nie oznacza, że złamanie tego będzie
> trudniejsze niż po mieszaniu 1-krotnym.
>
> BTW: co rozumiesz przez "mieszanie"? Permutację bitów?

Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion
znanych!! permutacji zastąpiłby jedną wynikową.
Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się
zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest
złamany).
A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej
hipotezy.

>
>>O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie
>>wypowiadać.
>>Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z
>
> Bo tak właśnie działa kryptografia asymetryczna: jeden klucz ma
> użytkownik i nikomu go nie ujawnia, a mimo to można stwierdzić
> zgodność jawnego klucza publicznego z tym prywatnym.

Przypuszczałem, że ustanowienie sesji między komputerem a systemem banku
opiera się na kryptografii asymetrycznej i że to jest to, co ma uniemożliwić
bankowi spreparowanie operacji.
Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz
prywatny - pewnie to jest najlepsze rozwiązanie.

Generalnie wypowiadałem się na temat: Jak powinno wyglądać logowanie, przy
założeniu, że użytkownik identyfikuje się zestawem login, hasło.
P.G.

do góry

On Thu, 16 Sep 2010 13:31:22 +0200, Piotr Gałka
<p...@C...pl> wrote:

>
>Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
>news:04p396tlpn7sib7ojpr3067jkm0b7n8lbh@4ax.com...
>>
>> ale milion mieszań wcale nie oznacza, że złamanie tego będzie
>> trudniejsze niż po mieszaniu 1-krotnym.
>>
>> BTW: co rozumiesz przez "mieszanie"? Permutację bitów?
>
>Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion
>znanych!! permutacji zastąpiłby jedną wynikową.
>Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się
>zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest
>złamany).
>A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej
>hipotezy.

A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego: tak
zmodyfikować wiadomość (lub inaczej: znaleźć taką wiadomość), aby
skrót był taki sam, jak dla wiadomości oryginalnej.

Można wielokrotnie wykonywać przekształcenie, ale idea jest taka:
http://en.wikipedia.org/wiki/Hash_chain
albo taka (połączenie wyniku kilku algprytmów):
http://en.wikipedia.org/wiki/Cryptographic_hash_func
tion#Concatenation_of_cryptographic_hash_functions


A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".

>Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz
>prywatny - pewnie to jest najlepsze rozwiązanie.

to właśnie jest istota algorytmu _asymetrycznego_. Jeśli klucz jest
znany obu stronom - to jest kryptografia symetryczna.

do góry

Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
news:9d0496djmqta15hb78lectj281eds467j8@4ax.com...
>
> A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
> bezpieczniejszy niż wykonany 1 raz?

A ja stawiałem taką tezę ?
Nie mówię o łamaniu SHA-256 tylko o ataku na hasła poprzez sprawdzanie
pewnej listy prawdopodobnych haseł w oparciu o domniemane zwyczaje
użytkowników. Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po
takim "wydłużeniu" nadal musi sprawdzić 2^48, ale pracy będzie miał przy tym
jakby sprawdzał hasła z przestrzeni 2^68 (licząc liczbę niezbędnych operacji
kryptograficznych do wykonania, porównanie=operacja, SHA=operacja). Gdyby
chciał pominąć to "wydłużenie" i atakować poprzez sprawdzanie wszystkich
możliwych wyników to musiałby sprawdzać 2^256 kombinacji, bo tu nie da się
stworzyć listy prawdopodobnych wybranych przez użytkownika wartości.
Zakładam, że taki atak jest znacznie prostszy od próby łamania SHA-256 i
wykonanie SHA-256 milion razy nie ma na celu jego wzmacniania.

> Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego:

To (według mnie) nie jest tematem tej dyskusji.

> Można wielokrotnie wykonywać przekształcenie, ale idea jest taka:
> http://en.wikipedia.org/wiki/Hash_chain

Rzuciłem (niedokładnie) okiem - to jest jakaś zupełnie inna bajka - chodzi o
to, aby za każdym razem inne hasło było przesyłane. Jeśli łącze jest
odpowiednio zabezpieczone to nie widzę takiej potrzeby.

> albo taka (połączenie wyniku kilku algprytmów):
> http://en.wikipedia.org/wiki/Cryptographic_hash_func
tion#Concatenation_of_cryptographic_hash_functions

Nie mam powodów aby wątpić, że poskładanie wielu funkcji hash nie jest
bezpieczniejsze od wykonania jedynie najmocniejszej z nich.

> A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".
>
Zgodzę się, choć dla mnie słowo "mieszanie" lepiej oddaje wykonywaną
operację, a "funkcja skrótu" sugeruje, że wynik jest krótszy od oryginału, a
to akurat w tym przypadku raczej nie jest prawdą (nigdy nie stosowałem
jeszcze 32 znakowych haseł).
P.G.

do góry

On Thu, 16 Sep 2010 14:54:37 +0200, Piotr Gałka
<p...@C...pl> wrote:

>
>Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
>news:9d0496djmqta15hb78lectj281eds467j8@4ax.com...
>>
>> A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
>> bezpieczniejszy niż wykonany 1 raz?
>
>A ja stawiałem taką tezę ?

Tak.

Cytat (Message-ID: <4c908574$1@news.home.net.pl>):

Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania) i dopiero takie wysyłane do systemu
banku /.../

Teraz piszesz:

>Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
>jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po

a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
bodajże 12-bitowy).

A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
identycznych haseł da różne skróty.
--
pozdrawiam,
Jarek Andrzejewski

do góry

Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
news:ru5496h1um3uck243n521d3231fb33nnge@4ax.com...

>>> A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
>>> bezpieczniejszy niż wykonany 1 raz?
>>
>>A ja stawiałem taką tezę ?
>
> Tak.
>
> Cytat (Message-ID: <4c908574$1@news.home.net.pl>):
>
> Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
> (np. milion operacji mieszania) i dopiero takie wysyłane do systemu
> banku /.../

Tu nie ma nic o zwiększeniu bezpieczeństwa funkcji hash przez jej
wielokrotne wykonanie, a jedynie o wydłużeniu hasła.

> Teraz piszesz:
>
>>Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
>>jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to
>>po
>
Czyli powtarzam to samo, co wcześniej napisałem, bo wygląda, że nie zostało
zrozumiane.

> a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
> bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
> bodajże 12-bitowy).

W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie
jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.
O soli pisałem tak: (Message-ID: <4c91e223$1@news.home.net.pl> )
----------
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego
użytkownika innej powoduje, że atakujący nie może stworzyć jednej tablicy
dla wszystkich użytkowników, ale musi tworzyć osobne tablice dla każdego
użytkownika.
----------

> A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
> identycznych haseł da różne skróty.

Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład
obliczeniowy atakującego.

Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło,
s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.
Wydłużenie o 20 bitów to r = milion, a sól to s w tym algorytmie.
Wydłużenie to co innego, a sól to co innego. Ja piszę o wydłużeniu to Ty
zauważasz: "a to nic nowego to sól".
Jak napiszę o soli (już pisałem wczoraj koło 11-tej) to w odpowiedzi
zobaczę: "a to nic nowego to wydłużanie".
Dla mnie chaos nie dyskusja.
P.G.

do góry

On Thu, 16 Sep 2010 16:28:09 +0200, Piotr Gałka
<p...@C...pl> wrote:

>Tu nie ma nic o zwiększeniu bezpieczeństwa funkcji hash przez jej
>wielokrotne wykonanie, a jedynie o wydłużeniu hasła.

do wydłużenia hasła wystarczy wygenerowanie (pseudo)losowo
parudziesięciu bitów. Nie rozumiem więc, po co proponujesz "milion
operacji mieszania".

>W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie
>jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.

możesz dać jakiś link do tej metody? Nie spotkałem się z
wykorzystaniem "miliona operacji mieszania" w celu wydłużenia hasła.

>Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład
>obliczeniowy atakującego.

ale skąd mają się te dodatkowe bity wziąć?

>Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło,
>s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.

podaj jakiś link, bo nie jestem przekonany, że milion takich
przekształceń jakoś istotnie zwiększa bezpieczeństwo - przekształcenie
jest deterministyczne, a p i s są jedynymi niewiadomymi.
--
pozdrawiam,
Jarek Andrzejewski

do góry

Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
news:7fa496lekk93851qg8c6aus7fj7m3kip41@4ax.com...

>
> do wydłużenia hasła wystarczy wygenerowanie (pseudo)losowo
> parudziesięciu bitów. Nie rozumiem więc, po co proponujesz "milion
> operacji mieszania".

Przy (podobno) obowiązkowym w kryptologii założeniu, że algorytmy są znane
atakującemu wygenerowanie pseudolosowo nic nie daje, a wygenerowanie losowo
nie ma tu sensu.
Używam słowa "wydłużenie" w zupełnie innym sensie.
Mam wrażenie, że nie czytasz tego co piszę. Już 2 razy tłumaczyłem jaki jest
cel czyli odpowiedź na pytanie "po co".

>>W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to
>>nie
>>jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.
>
> możesz dać jakiś link do tej metody? Nie spotkałem się z
> wykorzystaniem "miliona operacji mieszania" w celu wydłużenia hasła.
>

Nie mam linku. Informacja pochodzi z książki którą już wspominałem wczoraj
rano:
Message-ID: <4c9090b0$1@news.home.net.pl>
---------------
Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w
praktyce":
"22.2.1. Solenie i rozciąganie..... Techniki te są tak proste i naturalne,
że powinny być stosowane we wszystkich systemach haseł. Ignorowanie ich nie
ma żadnego wytłumaczenia."
----------------
Dodam, że autorzy to Neils Ferguson i Bruce Schneier. Głowy nie dam, ale to
chyba światowi eksperci w zakresie bezpieczeństwa systemów
kryptograficznych.
Opisywali tam też karygodny błąd w implementacji wydłużania (rozciągania) w
jakimś systemie którego bezpieczeństwo mieli zbadać. Programista, aby
użytkownik nie musiał czekać 1s aż się ten milion operacji wykona
zapamiętywał CRC hasła i szybko sprawdzał, że OK, a potem brał się za ten
milion przeliczeń.
P.G.

>>Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład
>>obliczeniowy atakującego.
>
> ale skąd mają się te dodatkowe bity wziąć?
>
Tłumaczyłem 2 posty wyżej (cytat):
------------
Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po
takim "wydłużeniu" nadal musi sprawdzić 2^48, ale pracy będzie miał przy tym
jakby sprawdzał hasła z przestrzeni 2^68 (licząc liczbę niezbędnych operacji
kryptograficznych do wykonania, porównanie=operacja, SHA=operacja).
-------------
To nie są prawdziwe bity, tylko pozorne - że pracy jest tyle jakby one były.

>>Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r,
>>p-hasło,
>>s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.
>
> podaj jakiś link, bo nie jestem przekonany, że milion takich
> przekształceń jakoś istotnie zwiększa bezpieczeństwo - przekształcenie
> jest deterministyczne, a p i s są jedynymi niewiadomymi.

Znów szybkość kosztem dokładności (chaos): s nie jest niewiadomą - jest
jawne z założenia.
Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy
zwiększa koszt ataku "brute force" na hasła.
P.G.

do góry

On Thu, 16 Sep 2010 17:17:13 +0200, Piotr Gałka
<p...@C...pl> wrote:

>Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w
>praktyce":

Mam, można rzec, że to "biblia".

>Dodam, że autorzy to Neils Ferguson i Bruce Schneier. Głowy nie dam, ale to
>chyba światowi eksperci w zakresie bezpieczeństwa systemów

zgadza się.
Fakt, że ostatnio jej nie czytałem.

>Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy
>zwiększa koszt ataku "brute force" na hasła.

Tak, to może mieć sens.
Sprawdzę, jak będę miał książkę pod ręką.

--
pozdrawiam,
Jarek Andrzejewski

do góry

Użytkownik "Jarek Andrzejewski" <p...@g...com> napisał w wiadomości
news:hbd49611p8rs13ljc957krk6qds2qjb7m5@4ax.com...
>
>>Nie zwiększa bezpieczeństwa w sensie łamania algorytmów, ale milion razy
>>zwiększa koszt ataku "brute force" na hasła.
>
> Tak, to może mieć sens.

Zachodzę w głowę dlaczego musiałem to 3 razy tłumaczyć ?
P.G.

do góry

"kashmiri" <n...@n...com> writes:

> Aplikacja dostępna dla "zwykłego" personelu w brytyjskim banku HSBC
> pokazuje hasło w całości. Wystarczy, że personel w dowolnym oddziale
> wpisze numer okazanej karty debetowej, aby pokazał się login i hasło
> klienta. Byłem zszokowany, kiedy to zobaczyłem - również tym, że HSBC
> jak by nie patrzeć ma jakąś renomę.

Obawiam sie ze renoma nie ma z tym wielkiego zwiazku.

To haslo potrzebne tylko przy dostepie przez Internet? IOW, nie jest
przydatne w oddziale?

W przypadku hasel, ktore ma "sprawdzac" pracownik (klient podaje haslo
pracownikowi w oddziale albo przez telefon, nie komputerowi), tak sie
robi, bo pracownik czesto nie moglby wprowadzic poprawnie hasla. Ale dla
hasla "internetowego" nie mam wytlumaczenia :-(
--
Krzysztof Halasa

do góry