On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 15:34:28 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>>
>> No własnie. Brak kiepskiej analizy bezpieczeństwa jest ryzykiem. Ryzyko
>> twojego fuckupu zostało pewnie wliczone, ale to nie znaczy, że system
>> jest bezpieczny. Po prostu stwierdzono, że nie musi być bezpieczny (i to
>> jest w porządku; nie wszystko musi być ogrodzone zasiekami i polem
>> minowym).
> Jest bezpieczny chociazby z powodu odpowiedzialnosci finansowej za
> niego.

Nie, mój drogi. Prawny dupochron nie wpływa bezpośrednio na
bezpieczeństwo systemu, służy jedynie ukierunkowaniu konsekwencji. Znowu
mieszasz dwa różne światy.

>> Częsty błąd laików. To, że dowód jest prosty jeszcze nie znaczy, że
>> obejmuje wszystkie potrzebne przypadki i możliwe ataki.
> Ale właśnie prostota polega na tym, że możliwych przypadków jest mało.

Przypadków przewidzianych. Skąd wiadomo że obsłużyłeś wszystkie
przypadki, w tym te nieoczywiste? Jako laik możesz sobie nie zdawać
sprawy ze wszystkich metod wyciekania danych. Specjalistom się rzadko
udaje wszystko przewidzieć, a ty uważasz, że tobie akurat jednemu się
udało?

>> A skąd ten pomysł? Może zawodowiec będzie miał możliwość przeprowadzenia
>> ataku tylko w tym jednym miejscu?
> To system nadal jest bezpieczny, bo wtedy ja pokrywam koszty za straty.

Nie. To nie jest system bezpieczny, tylko ubezpieczony prawnie.
Analogicznie, jeśli *ubezpieczysz* samochód od kradzieży, to jeszcze nie
znaczy, że jest *zabezpieczony*. Nie znaczy jeszcze, że możesz nie
zamykać drzwi.

>> Już pisałem: twoje odczucie jako autora jest nieistotne. Ty jesteś
>> przekonany o tym, że obsłużyłeś wszystkie możliwe (albo choćby sensowne)
>> scenariusze, bo inaczej włączyłbyś to, czego brakuje, do systemu.
>> Sytuacja taka sama jak z testowaniem softu: autor kodu nie powinien tego
>> robić sam.
> W czym problem? Wielokrotnie, a w przypadku prostego softu niemal zawsze,
> udawało mi się obsłużyć wszystkie przypadki.

W tym, że wtedy pisałeś soft, a nie tworzyłeś kryptosystemy.
Z kryptosystemów najprawdopodobniej jesteś dupa (nie masz przeszkolenia,
a w samorodny talent w tym przypadku nie wierzę) i nie ma podstaw
sądzić, że udało ci się wszystko przewidzieć.

>> Właśnie. Dlatego twoją analizę bezpieczeństwa można o kant dupy rozbić
>> (jesteś autorem i nie masz przygotowania z bezpieczeństwa).
>> Zaznaczam, że to nie dyskwalifikuje samego produktu. To jedynie
>> dyskwalifikuje analizę.
> Jedno z drugim nie może współistnieć. Albo analiza dobra i dobry produkt, albo
> w analizie coś pomiąłem i produkt do dupy.

Ty to stwierdziłeś. Ja jedynie dyskwalifikuję twoją analizę (z dwóch
ważnych powodów podanych wyżej).

>> Aha. Czyli w sumie żaden argument, ot, taka anegdota do opowiadania
>> w towarzystwie. Gościu może po prostu nie miał motywacji (pieniądze?
>> sława? nauczenie się czegoś nowego? dobra łamigłówka? chęć popisania
>> się?), żeby się tym w ogóle zająć, może był za głupi, a może algorytm
>> rzeczywiście taki wypasiony.
> Argumentował że jego doświadczenie/wykształcenie jest spore, a
> sposób łamania banalny - potem nie złamał.

Nadal: może nie miał motywacji, żeby w ogóle myśleć o tej sprawie? Tak
przedstawiona historia jest jedynie anegdotą i nie ma żadnej wartości
jako argument za twoimi zdolnościami kryptograficznymi.

--
Secunia non olet.
Stanislaw Klekot