No, uz jednou takhle nekdop udelal exploit na casino ... nejake casino aby dokazalo jak "je jejich software ferovy" tak zverejnilo kus zdrojaku, kde bylo videt, jak se nahodne cislo generuje.
Jenze melo to jednu chybku - byl to 32bitovy pseudonahodny jednoduchy generator (standardni random() v delphi). Dalsi problem byl v tom, se se seedoval pred kazdym rozdanim karet a zdrojem seedu je tam pocet milisekund od zacatku dne .... cimz se pocet moznych random hodnot seedu zuzil pry asi na 200000 (je tu nejaka odlisnost v casu mezi serverem a klientem a tak, uz si nepamatuju kolik seedu to bylo, ale raqdove o dost min nez 2^32 ...)
For byl v tom, ze podle prvnich peti liznutych karet slo zjistit ktery z tech 200000 seedu na serveru je a jakych dalsich 5 karet mi server da, takze clovek pak vedel ktery karty si ma vymenit a jestli vyhraje - kdyz jo, tak zvednu sazku ....
Ale je fakt, ze tam byl ten bug se seedem, bez nej by bylo treba prohledavat 2^32 hodnot, coz by bylo o dost horsi .... vicemene nepouzitelny...
Napr. nmap dokaze vyuzit predikovatelne generovanie IPID na blind zombie scan (option -sI). Najjednoduchsie je, ked sa IPID zvacsuje postupne pricitanim nejakej konstanty, napr. 1000 - (broken) little-endian incremental (toto typicky robia Win95, Win98). Keby sa na to pouzil linearny kongruencny generator (LCG), ako je napr. funkcia rand(), tak by sa z dvoch ziskanych hodnot IPID dali vypocitat dalsie, takze by to neposkytovalo o nic vacsiu bezpecnost nez pricitanie konstanty.
Pri SSL/TLS by pouzitie predikovatelneho generatora ako napr. LCG umoznovalo odpocuvat a desifrovat spojenie.
No teraz som si neni isty, ci rozumiem otazke..."viac nahodne nez normalne nahodne" = ?
Inak s tym nmapom to naozaj funguje, staci si na nete najst nejaky vhodny zombie stroj (cf. http://www.insecure.org/nmap/idlescan.html).
Nahodnost sa skuma kvoli tomu, aby sa nepouzili blbe generatory na nevhodnych miestach, potom by sme uz nemali "kdyby", ale riadny pruser ;-)
Len maly priklad: V praci http://eprint.iacr.org/2003/052.pdf sa popisuje utok na SSL/TLS pomocou postrannych kanalov zalozenych na tom, ze sifrovanie RSA rozlicnymi klucmi v urcitych implementaciach trva rozlicne dlhu dobu a teda je mozne invertovat RSA. Tato praca nema sice malo spolocne s (pseudo)nahodnymi generatormi (PRNG), ale pouzitie zleho generatoru ma podobny dopad: ak sa da nejak z postrannych kanalov uhadnut interny stav PRNG, utocnik uz vie generovat rovnake pseudonahodne postupnosti a rekonstruovat vsetky operacie, kde takto vygenerovane hodnoty vstupuju. Nemusi byt ani schopny uhadnut interny stav, ak dokaze napr. z casti postupnosti vypocitat, ze dalsie vygenerovane cislo bude lezat v nejakom hodne obmedzenom rozsahu.
Inak povedane, ak utocnik dokaze aspon z casti predpovedat vystup PRNG, dokaze obmedzit prehladavany priestor. Ak ho dokaze obmedzit dostatocne, tak zrazu brute-force v obmedzenom priestore moze za nejaky rozumny cas dat vysledok (napr. tajnu hodnotu, kluc, atd.).
Jo, ja :-). Bylo to tak, ze na jednom webu zverejnovali data, ale jen cast a oproti registraci. Kdyz se clovek zaregistroval (zadal mail a heslo), vytvorili mu ucet s ID a heslem a dali mu vedet na mail (ten zadany). To ID bylo generovano "nahodne". Ja jsem si nechal zaregistrovat tri maily a z tech tri ID jsem byl schopny urcit dalsi a dalsi. Takze jsem si pak z jejich WEB formulare nechal zaregistrovat jednu mailovou adresu a nasledne X neexistujicich adres (kde X >> 100 :-)). Na tu prvni existujici mi prislo ID a ja jsem z toho byl schopen urcit i ty dalsi, takze jsem nepotreboval, aby mi doslo tech X mailu (samozrejme nikam nedosly, protoze jsem si ty adresy vymyslel, ale ucty s danym heslem uz byly vytvoreny a ja jsem byl schopen odvodit prislusna ID).
Je to legracka, samozrejme jsem si mohl zaregistrovat X mailovych adres, ale tohle bylo (pri danem poctu registraci) mnohem rychlejsi a vyhodnejsi :-).
Btw. slo o dokumentaci, kterou poskytovali v omezene mire! Clovek si mohl vybrat dokumenty, ktere chtel, ale mohl si stahnout pouze urcity pocet dokumentu. No a ja jsem chtel vsechny :-).