W dniu 2013-01-22 15:57, M.M. pisze:
> 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.

Ubezpieczenie auta od kradzieży powoduje, że jest ono
zabezpieczone przed kradzieżą? To zabezpiecza przed
poniesieniem (większości) strat związanych z kradzieżą,
nie przed samą kradzieżą.

Ale to dyskusja o słowniku:)


>> 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.

Bardzo prosty przypadek. Kodowanie RSA.
Mamy dwie liczby pierwsze p,q, publikujemy ich iloczyn i jeszcze
jedną liczbę e(p,q). Ktoś tym koduje, my odczytujemy za pomocą p i q.

I bardzo prosty dowód bezpieczeństwa: potrzeba mieć p i q, a p*q
ciężko rozdzielić, jesteśmy wiec bezpieczni. A e jest bez znaczenie...

Tylko, czy na pewno to e nigdy pomaga w rozłożeniu p*q? :)


> Argumentował że jego doświadczenie/wykształcenie jest spore, a
> sposób łamania banalny - potem nie złamał.

Kiedyś na wydziale informatyki spotkałem gościa, co właśnie
kończył zdobywać papier potwierdzający wykształcenie i święcie
wierzył,że jak będzie liczył na GPU to pokona algorytm na
procesorze o lepszej złożoności, niezależnie od wielkości danych;)


pzdr
bartekltg