On 2014-11-10 10:37, g...@g...com wrote:
[...]
> Hmm. Przywodzi na mysl kod zrodlowy popularnego ostatnio serwera NGINX.
> Mozna znalezc tam takie kwiatki, jak
>
> if ((c[0] == 'S'|| c[0] == 's')
> && (c[1] == 'T'|| c[1] == 't')
> && (c[2] == 'A'|| c[2] == 'a')
> && (c[3] == 'R'|| c[3] == 'r')
> && (c[4] == 'T'|| c[4] == 't')
> && (c[5] == 'T'|| c[5] == 't')
> && (c[6] == 'L'|| c[6] == 'l')
> && (c[7] == 'S'|| c[7] == 's'))
>
> autentyk.
> https://github.com/nginx/nginx/blob/master/src/mail/
ngx_mail_parse.c
>
Ale to w sam raz może być optymalizacja ze względu na wydajność (nie
wiem czy słuszna). Kiedyś, studiując jakąś implementację LZ77, natknąłem
się na wyszukiwanie ciągu znaków w słowniku AFAIR w taki sposób (p i s
to wskaźniki na tablicę char-ów):

*p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
*p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
*p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
*p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++

i dopiero tutaj była pętla w przypadku dłuższych trafień.

do góry

On Monday, November 10, 2014 5:53:59 PM UTC+1, JDX wrote:
> > Hmm. Przywodzi na mysl kod zrodlowy popularnego ostatnio serwera NGINX.
> > Mozna znalezc tam takie kwiatki, jak
> >
> > if ((c[0] == 'S'|| c[0] == 's')
> > && (c[1] == 'T'|| c[1] == 't')
> > && (c[2] == 'A'|| c[2] == 'a')
> > && (c[3] == 'R'|| c[3] == 'r')
> > && (c[4] == 'T'|| c[4] == 't')
> > && (c[5] == 'T'|| c[5] == 't')
> > && (c[6] == 'L'|| c[6] == 'l')
> > && (c[7] == 'S'|| c[7] == 's'))
> >
> > autentyk.
> > https://github.com/nginx/nginx/blob/master/src/mail/
ngx_mail_parse.c

Tu jest sprytne porównanie case insensitive. :)

> Ale to w sam raz może być optymalizacja ze względu na wydajność (nie
> wiem czy słuszna). Kiedyś, studiując jakąś implementację LZ77, natknąłem
> się na wyszukiwanie ciągu znaków w słowniku AFAIR w taki sposób (p i s
> to wskaźniki na tablicę char-ów):
>
> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++
>
> i dopiero tutaj była pętla w przypadku dłuższych trafień.

Możliwe, że w starszych kompilatorach to coś dawało, bo to
jedynie ręcznie rozwinięta pętla

int i=0;
while (*p == *s && i < 16) {
p++; s++; i++
}

GCC 4.9 sobie z tym oryginalnym kodem w ogóle nie poradził,
w sensie, że nie zrobił żadnej spektakularnej optymalizacji. :)

Zdecydowanie lepiej byłoby porównywać w porcjach równych
rozmiarom rejestru maszynowego (32 lub 64 bity) bo to się
przekłada na pojedyncze instrukcje, a dopiero po
niedopasowaniu porównywać poszczególne bajty.

w.

do góry

On Sunday, November 9, 2014 3:51:10 PM UTC+1, bartekltg wrote:
> Ciekawy kwiatek
>
> https://github.com/haiwen/ccnet/issues/35
> https://github.com/haiwen/ccnet/blob/master/net/serv
er/user-mgr.c#L612
>
> /* -------- EmailUser Management -------- */
> /* truly random sequece read from /dev/urandom. */
> static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7,
> 0xcc, 0x26 };
>
> I ta tabelka użyta jest przynajmniej w funkcji hash_password_salted.
Dlaczego nazywasz to kwiatkiem?

Pozdrawiam

do góry

On 11.11.2014 15:07, M.M. wrote:
> On Sunday, November 9, 2014 3:51:10 PM UTC+1, bartekltg wrote:
>> Ciekawy kwiatek
>>
>> https://github.com/haiwen/ccnet/issues/35
>> https://github.com/haiwen/ccnet/blob/master/net/serv
er/user-mgr.c#L612
>>
>> /* -------- EmailUser Management -------- */
>> /* truly random sequece read from /dev/urandom. */
>> static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7,
>> 0xcc, 0x26 };
>>
>> I ta tabelka użyta jest przynajmniej w funkcji hash_password_salted.

> Dlaczego nazywasz to kwiatkiem?

Z tego co rozumiem (specem od kryptografii nie jestem) 'solenie'
jednym z jego zadań jest uodpornienie na atak 'tęczowymi tablicami'.

Atakujący może sobie odpowiednio przygotować tablicę (sporych
rozmairów:), która umożliwi mu szybkie odwrócenie hashy.
Ludzie lubią używać krótkich haseł;-)
Dodanie losowego ciągu po haśle (czy szerzej, hash przyjmuje dwa
argumenty, hasło i liczbę losową) powoduje, że te tablice musiałby
być niepraktycznie duże. Dla każdej soli nowa tablica.

Zapisanie tego na sztywno spowoduje co prawda, że uniwersalna tablica
będzie mało przydatna, ale koszt odwrócenia jednego hasha
jest w praktyce taki sam, jak odwrócenia wszystkich.
Do tego ciąg jest dość krótki.

Ale jak wspomniałem na początku, znam się bardzo umiarkowanie;-)

pzdr
bartekltg

do góry

On Tuesday, November 11, 2014 4:07:40 PM UTC+1, bartekltg wrote:
> > Dlaczego nazywasz to kwiatkiem?
>
> Z tego co rozumiem (specem od kryptografii nie jestem) 'solenie'
> jednym z jego zadań jest uodpornienie na atak 'tęczowymi tablicami'.
>
> Atakujący może sobie odpowiednio przygotować tablicę (sporych
> rozmairów:), która umożliwi mu szybkie odwrócenie hashy.
> Ludzie lubią używać krótkich haseł;-)
> Dodanie losowego ciągu po haśle (czy szerzej, hash przyjmuje dwa
> argumenty, hasło i liczbę losową) powoduje, że te tablice musiałby
> być niepraktycznie duże. Dla każdej soli nowa tablica.
>
> Zapisanie tego na sztywno spowoduje co prawda, że uniwersalna tablica
> będzie mało przydatna, ale koszt odwrócenia jednego hasha
> jest w praktyce taki sam, jak odwrócenia wszystkich.
> Do tego ciąg jest dość krótki.
>
> Ale jak wspomniałem na początku, znam się bardzo umiarkowanie;-)

Dziekuje za wyjasnienia. I ja pecem od krypografii nie jestem.

Moje wyobrazenie na temat solenia jest takie, ze jesli kody
zrodlowe nie wyciekna, to aby zrobic operacje odwrotna, trzeba
sprawdzic wszystkie mozliwe algorytmy, a wiec jest to niemozliwe.
Natomiast jesli wyciekna, to do najbardziej wyrafinowanych
algorytmow mozna zrobic operacje odwrotna. Na pewno zdarzaja sie
tez sytuacje posrednie, czyli takie, ze kody zrodlowe nie wyciekly, a
atakujacy odgaduje iz uzyto jakiegos prostego algorytmu.

Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
losowy ciag wstawiam w losoych miejscach znaki hasla.

Wracajac do tematu, tamta losowo-stala tabica, niekoniecznie oznacza
totalny bubel. Moze autor jakos sensownie uzyl tamtej tablicy i jesli kody
nie wyciekna, to nie ma duzo wiekszego niebezpieczenstwa niz w
przypadku losowej? No chyba ze faktycznie te same znaki dokleja na
koncu kazdego hasla po zahashowaniu ;-)

Pozdrawiam

do góry

On Monday, November 10, 2014 8:03:36 PM UTC+1, Wojciech Muła wrote:
> Zdecydowanie lepiej byłoby porównywać w porcjach równych
> rozmiarom rejestru maszynowego (32 lub 64 bity) bo to się
> przekłada na pojedyncze instrukcje, a dopiero po
> niedopasowaniu porównywać poszczególne bajty.
Najlepiej jesli mozna wyrownac dlugosc ciagow do wielokrotnosci
rozmiaru slowa maszynowego.
Pozdrawiam

do góry

On 11.11.2014 16:35, M.M. wrote:
> On Tuesday, November 11, 2014 4:07:40 PM UTC+1, bartekltg wrote:
>>> Dlaczego nazywasz to kwiatkiem?
>>
>> Z tego co rozumiem (specem od kryptografii nie jestem) 'solenie'
>> jednym z jego zadań jest uodpornienie na atak 'tęczowymi tablicami'.
>>
>> Atakujący może sobie odpowiednio przygotować tablicę (sporych
>> rozmairów:), która umożliwi mu szybkie odwrócenie hashy.
>> Ludzie lubią używać krótkich haseł;-)
>> Dodanie losowego ciągu po haśle (czy szerzej, hash przyjmuje dwa
>> argumenty, hasło i liczbę losową) powoduje, że te tablice musiałby
>> być niepraktycznie duże. Dla każdej soli nowa tablica.
>>
>> Zapisanie tego na sztywno spowoduje co prawda, że uniwersalna tablica
>> będzie mało przydatna, ale koszt odwrócenia jednego hasha
>> jest w praktyce taki sam, jak odwrócenia wszystkich.
>> Do tego ciąg jest dość krótki.
>>
>> Ale jak wspomniałem na początku, znam się bardzo umiarkowanie;-)
>
> Dziekuje za wyjasnienia. I ja pecem od krypografii nie jestem.
>
> Moje wyobrazenie na temat solenia jest takie, ze jesli kody
> zrodlowe nie wyciekna, to aby zrobic operacje odwrotna, trzeba
> sprawdzic wszystkie mozliwe algorytmy, a wiec jest to niemozliwe.
> Natomiast jesli wyciekna, to do najbardziej wyrafinowanych
> algorytmow mozna zrobic operacje odwrotna. Na pewno zdarzaja sie

Nieprawda. Bezpieczeństwo tego typu metod nie opiera się na tym,
że nie wiemy, jak ktoś coś hashuje, tylko na tym, że funkcja,
która hashuje jest trudna do odwrócenia.
Zobaczy ile jest gotowców:-) Kryptograficzne programy open source
też istnieją ;-) Jeśli "przeciwnik" nie wie, co dokładnie robimy,
to dodatkowy plus (z drugiej strony, jeśli nie jesteś NSA czy choćby
ABW, to Twoją tajną metodę przetestowało znacznie mniej osób, skąd
wiesz, czy nie ma tam jakiejś brzydkiej matematycznej dziury;).

> tez sytuacje posrednie, czyli takie, ze kody zrodlowe nie wyciekly, a
> atakujacy odgaduje iz uzyto jakiegos prostego algorytmu.

Zakładam brak aż takiego partactwa, jak użycie xor'a ;-)


> Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
> losowy ciag wstawiam w losoych miejscach znaki hasla.

To z grubsza to samo.


> Wracajac do tematu, tamta losowo-stala tabica, niekoniecznie oznacza
> totalny bubel. Moze autor jakos sensownie uzyl tamtej tablicy i jesli kody
> nie wyciekna, to nie ma duzo wiekszego niebezpieczenstwa niz w
> przypadku losowej? No chyba ze faktycznie te same znaki dokleja na
> koncu kazdego hasla po zahashowaniu ;-)

Wczytałem się tylko na tyle, by sprawdzić, że tej tablicy gdzieś
używa (a nuż był to tylko dowcip na cześć xkcd dowcip), głębiej
nie czytałem.

pzdr
bartekltg

do góry

On Tuesday, November 11, 2014 9:45:43 PM UTC+1, bartekltg wrote:
> > Natomiast jesli wyciekna, to do najbardziej wyrafinowanych
> > algorytmow mozna zrobic operacje odwrotna. Na pewno zdarzaja sie
>
> Nieprawda. Bezpieczeństwo tego typu metod nie opiera się na tym,
> że nie wiemy, jak ktoś coś hashuje, tylko na tym, że funkcja,
> która hashuje jest trudna do odwrócenia.
No tak, zakladamy ze nie istnieje (albo chociaz nie jest znany)
szybki algorytm odwracana i trzeba lamac burtforcem. Zakladamy
ze user wpisal krotkie haslo skladajace sie z 3 znakow. Pytanie
brzmi, czy istnieje algorytm osolenia, ktory uniemozliwi odkodowanie
tego hasla metoda burforce, nawet gdy lamacz wie, w jaki sposob
zostalo osolone? Moim zdaniem przez losowe osolenie, mozna co
najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
kazde haslo po kolei. Czy myle sie?



> Zobaczy ile jest gotowców:-) Kryptograficzne programy open source
> też istnieją ;-) Jeśli "przeciwnik" nie wie, co dokładnie robimy,
> to dodatkowy plus (z drugiej strony, jeśli nie jesteś NSA czy choćby
> ABW, to Twoją tajną metodę przetestowało znacznie mniej osób, skąd
> wiesz, czy nie ma tam jakiejś brzydkiej matematycznej dziury;).
Mysle podobnie.


> > Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
> > losowy ciag wstawiam w losoych miejscach znaki hasla.
>
> To z grubsza to samo.
W sumie racja. Funkcja skrotu to funkcja skrotu. Albo jest znana atakujacemu,
albo nie. Albo jest znany szybki algorytm odwracania, albo trzeba burtforcem.
Na ciag zaburzajacy mozna spojrzec jak na element funkcji skrotu.


> Wczytałem się tylko na tyle, by sprawdzić, że tej tablicy gdzieś
> używa (a nuż był to tylko dowcip na cześć xkcd dowcip), głębiej
> nie czytałem.
Ja tez nie wczytywalem sie. Jesli kazdy uzytkownik moze wpisac
te liczby sam przed kompilacja i jesli mozna sensownie bronic
przed wyciekiem tych liczb, to nie jest az taki bubel. Z kolei
jesli sposob osolenia wycieknie, to solac losowo, zyskujemy niewiele:
mozemy tylko ograniczyc lamanie od jednego hasla jednoczesnie.



Pozdrawiam

do góry

On 2014-11-11, M.M. <m...@g...com> wrote:
> On Tuesday, November 11, 2014 9:45:43 PM UTC+1, bartekltg wrote:

>> Nieprawda. Bezpieczeństwo tego typu metod nie opiera się na tym,
>> że nie wiemy, jak ktoś coś hashuje, tylko na tym, że funkcja,
>> która hashuje jest trudna do odwrócenia.
> No tak, zakladamy ze nie istnieje (albo chociaz nie jest znany)
> szybki algorytm odwracana i trzeba lamac burtforcem. Zakladamy
> ze user wpisal krotkie haslo skladajace sie z 3 znakow. Pytanie
> brzmi, czy istnieje algorytm osolenia, ktory uniemozliwi odkodowanie
> tego hasla metoda burforce, nawet gdy lamacz wie, w jaki sposob
> zostalo osolone? Moim zdaniem przez losowe osolenie, mozna co
> najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
> kazde haslo po kolei. Czy myle sie?

Mylisz się, niezależnie od tego, co twierdzisz za "składające się
z 3 znaków". W pierwszym rzędzie uniemożliwia się podanie tak krótkich
haseł.

>> > Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
>> > losowy ciag wstawiam w losoych miejscach znaki hasla.
>>
>> To z grubsza to samo.
> W sumie racja. Funkcja skrotu to funkcja skrotu. Albo jest znana atakujacemu,
> albo nie. Albo jest znany szybki algorytm odwracania, albo trzeba burtforcem.
> Na ciag zaburzajacy mozna spojrzec jak na element funkcji skrotu.

Nie. Sól jest po to, żeby podnieść koszt przygotowania wstępnie
przeliczonych danych o kilka rzędów wielkości. To nie ma nic wspólnego
z funkcją skrótu jako taką.

>> Wczytałem się tylko na tyle, by sprawdzić, że tej tablicy gdzieś
>> używa (a nuż był to tylko dowcip na cześć xkcd dowcip), głębiej
>> nie czytałem.
> Ja tez nie wczytywalem sie. Jesli kazdy uzytkownik moze wpisac
> te liczby sam przed kompilacja i jesli mozna sensownie bronic
> przed wyciekiem tych liczb, to nie jest az taki bubel.

Nie wiesz do czego służy sól, więc nie jesteś na odpowiedniej pozycji,
żeby oceniać czy to bubel czy nie.

> Z kolei
> jesli sposob osolenia wycieknie, to solac losowo, zyskujemy niewiele:
> mozemy tylko ograniczyc lamanie od jednego hasla jednoczesnie.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Tuesday, November 11, 2014 11:45:03 PM UTC+1, Stachu 'Dozzie' K. wrote:
> On 2014-11-11, M.M. <m...@g...com> wrote:
> > On Tuesday, November 11, 2014 9:45:43 PM UTC+1, bartekltg wrote:
>
> >> Nieprawda. Bezpieczeństwo tego typu metod nie opiera się na tym,
> >> że nie wiemy, jak ktoś coś hashuje, tylko na tym, że funkcja,
> >> która hashuje jest trudna do odwrócenia.
> > No tak, zakladamy ze nie istnieje (albo chociaz nie jest znany)
> > szybki algorytm odwracana i trzeba lamac burtforcem. Zakladamy
> > ze user wpisal krotkie haslo skladajace sie z 3 znakow. Pytanie
> > brzmi, czy istnieje algorytm osolenia, ktory uniemozliwi odkodowanie
> > tego hasla metoda burforce, nawet gdy lamacz wie, w jaki sposob
> > zostalo osolone? Moim zdaniem przez losowe osolenie, mozna co
> > najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
> > kazde haslo po kolei. Czy myle sie?
>
> Mylisz się, niezależnie od tego, co twierdzisz za "składające się
> z 3 znaków". W pierwszym rzędzie uniemożliwia się podanie tak krótkich
> haseł.
Byc moze sie myle, ale na pewno uzasadnienie jest inne.



> >> > Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
> >> > losowy ciag wstawiam w losoych miejscach znaki hasla.
> >>
> >> To z grubsza to samo.
> > W sumie racja. Funkcja skrotu to funkcja skrotu. Albo jest znana atakujacemu,
> > albo nie. Albo jest znany szybki algorytm odwracania, albo trzeba burtforcem.
> > Na ciag zaburzajacy mozna spojrzec jak na element funkcji skrotu.
>
> Nie. Sól jest po to, żeby podnieść koszt przygotowania wstępnie
> przeliczonych danych o kilka rzędów wielkości. To nie ma nic wspólnego
> z funkcją skrótu jako taką.
Piszesz ze nie, a podajesz takie same uzasadnienie jak moje. Nie rozumiem.


>
> >> Wczytałem się tylko na tyle, by sprawdzić, że tej tablicy gdzieś
> >> używa (a nuż był to tylko dowcip na cześć xkcd dowcip), głębiej
> >> nie czytałem.
> > Ja tez nie wczytywalem sie. Jesli kazdy uzytkownik moze wpisac
> > te liczby sam przed kompilacja i jesli mozna sensownie bronic
> > przed wyciekiem tych liczb, to nie jest az taki bubel.
>
> Nie wiesz do czego służy sól, więc nie jesteś na odpowiedniej pozycji,
> żeby oceniać czy to bubel czy nie.
Nie widze zadnego problemu, wystarczy ze Ty ocenisz i uzasadnisz.


Pozdrawiam

do góry