Vlákno názorů k článku ChaosKey: skutečný generátor náhodných čísel do USB od K> - Nahodnost cisel se da jednoduse testovat. Akorat nemuzu...
-
K> (neregistrovaný)
Nahodnost cisel se da jednoduse testovat. Akorat nemuzu nikde najit srovnani ChaosKey s nejakym jinym nahodnym generatorem. Na strankach projektu neni o tomhle vubec nic.
Vicemene mi vrta hlavou, jestli tenhle nahodny generator je opravdu o tolik lepsi nez bezne dostupne softwarove? Ma to vubec smysl resit externi hw generator?
-
Starous (neregistrovaný)
Přesně právě proto to vadí. Ideální random number generátor bude mít normální rozložení hodnot, tzn každé číslo bude vracet se stejnou pravděpodobností. CRC sice nějak to rozložení změní ale není tam zaručená vlastnost krypto hashů, že malá změna vstupu vede na velkou změnu výstupu. Proto očekávám že výsledek nebude normalizovaný resp bude v něm poznat vstup. A protože vstupní hodnoty jsou nerovnoměrné, resp nejčastější hodnota je ve středu tak to půjde i zlomit - je to jako kostka kde 3 a 4 padá nejčastěji. Lepší by bylo použit nějakou secure PRF místo crc
-
Martin Mareš (neregistrovaný)
Pokud výstup HW generátoru přimícháváte do poolu kernelového /dev/random, vůbec nepotřebujete, aby generátor měl rovnoměrné (což je mimochodem něco jiného než normální) rozdělení. V zásadě potřebujete pouze dostatečně konzervativní odhad entropie tohoto rozdělení, abyste věděl, "kolik náhodnosti dodává". To by fungovalo i bez "narovnávání rozdělení" CRCem. Tu "secure PRF" už /dev/random obsahuje.
-
FíkZlatý podporovatelten "whitening" algoritmus se tam dává vždy, aby nebylo víc nul než jedniček, s čímž by se potom špatně dělalo:
-
CRC (neregistrovaný)
záleží čo s tým CRC ďalej robia a ako ho využívajú, stačí sa pohrať najlepšie s assemblerom, aby to bolo rýchle a dá sa dopracovať k dobrým výsledkom - najviac mi však imponuje tá hláška od autorov projektu - že chaoskey je lepšie si postaviť sám a mal by byť vylepšovaný. Takže to CRC bol ich nápad - tento projekt by si zaslúžil oveľa väčšiu pozornosť, dúfam že sa do toho Open source komunita obuje a budú to rozvíjať.
-
FíkZlatý podporovatel
CRC je zmíněno v tom odkazu na Wikipedii, takže tak úplně to není jejich nápad
-
Filip JirsákStříbrný podporovatelDnes jsou v procesorech běžně dostupné hardwarové generátory náhody. Účelem ChaosKey není to, aby poskytoval ještě „náhodnější“ data – podle mne cílí na lidi, kteří se obávají, že ty generátory v procesorech může někdo zmanipulovat, aby v kritické situaci poskytovaly pro někoho předvídatelná data.
-
Karel (neregistrovaný)
Jen bych upřesnil, že ta determiničnost je právě to, co je ten zásadní problém. Proč? Používáte 4096 bitové šifrování? Kolik možností musíte zkusite na brute force útok? Dobře, a teď vám řeknu, že na vygenerování klíče byl použit deterministický generátor náhodných čísel. Běžel 5 minut a generoval 10000 náhodných čísel za sekundu. To je 300 sekund * 10000 = 3000000, 3 miliony. Nevím, které z nich je to správné. Ale můžu je zkusit všechny.
Proto jsou deterministické generátory tak špatný nápad pro kryptografii. Nemusím zkoušet 2^4096 možných kombinací. Když se použije špatný generátor, tak stačí třebas jen 2^24. A pokud se ještě použije špatně, tak to je klidně i jen pár tisíc čísel.
-
Vodník (neregistrovaný)
V běžném provozu je potřeba daleko víc náhodnosti než pár set bitů jednou ročně na vygenerování hlavního klíče (toho klíče, o kterém uživatel ví, chrání si ho a zálohuje). Jsou potřeba různé jednorázové klíče a jednorázové náhodné hodnoty, bez kterých by dané protokoly nebyly dost zabezpečené.
-
Palo (neregistrovaný)
Co myslite tym 'jednoduse'. Ide to iba velmi komplikovane. Tu mate napriklad sadu testov ktore to robia:
http://www.phy.duke.edu/~rgb/General/dieharder.phpExterny HW generator je o 2 rady lepsi nez to co vam lezia z procesora.
-
ebik (neregistrovaný)
Ano bavime se o "nahodnych cislech" - to je dost prazdny pojem. A muzeme se hadat jestli s toho lezou cisla zla nebo zeleno-ruzova.
Dulezite je k cemu se ta nahodna cisla maji pouzit. Pokud je chcete pouzit k vytvoreni sifrovaciho klice, tak PRNG nechcete v zadnem pripade, nekdo by totiz mohl zjistit cim byl naseedovan, obzvlast pokud by to byl nejaky "systemovy" PRNG a utocnik mel k dispozici treba pokracovani sekvence nahodnych cisel po vygenerovani toho klice (nebo jeste lepe kdyby mel par bajtu vytazenych z toho PRNG pred zacatkem generovani toho klice). Pokud ale chcete metodou monte-carlo merit pravdepodobnost nejakeho jevu, tak na to staci i nejaky hloupy PRNG, ktery ani neni kryptograficky bezpecny.
-
Jenda (neregistrovaný)
> Pokud je chcete pouzit k vytvoreni sifrovaciho klice, tak PRNG nechcete v zadnem pripade
O to bych se přel, a PRNG se velmi často k výrobě klíčů používá. Nebo si myslíš, že třeba mailserver s TLS má na každý handshake 256 bitů entropie pro výrobu session klíče?
> nekdo by totiz mohl zjistit cim byl naseedovan
Zde vidím problém pokud udělám třeba perfect forward secrecy a časem mě někdo vyhackuje. Proto se to občas (~minuta) přeseedovává.
> obzvlast pokud by to byl nejaky "systemovy" PRNG a utocnik mel k dispozici treba pokracovani sekvence nahodnych cisel po vygenerovani toho klice (nebo jeste lepe kdyby mel par bajtu vytazenych z toho PRNG pred zacatkem generovani toho klice)
Ne, proti tomuhle by měl být CSPRNG odolný. Pokud na to máš útok, tak jsi právě objevil třeba known-plaintext attack na AES v CTR módu.
-
ebik (neregistrovaný)
"O to bych se přel,..."
Tady jsem nemel na mysli sifrovaci klice pro symetricke sifry, ale sifrovaci klice pouzite napriklad v certifikatu s platnosti 10 let.
"proti tomuhle by měl být CSPRNG odolný"
Odolný bude v obecném případě: tedy neznám nic o jeho stavu, byl dobre naseedovan, potom se z jeho vystupu o jeho stavu nic nedozvim. Nicmene ne vsechny pripady jsou obecne, nekdy se muze stat, ze za nejakych okolnosti, napriklad vinou spatne implementace (ta se stava prekvapive casto), muzete mnozinu moznych vnitrnich stavu v nejakem jednom konkretnim okamziku nejak omezit, prave na zaklade znalosti okolnich podminek. Potom nemusi byt nerealne provest simulaci vsech moznych stavu (z te omezene mnoziny) a zjistit, ktery odpovida pozorovanemu vystupu.
"pokud na to mas utok..."
Zadny utok nemam, ale to neznamena, ze tam neni dira, v pripade bezpecnosti je treba byt opatrny, a overit vsechny predpoklady (matematicke, ale i technicke), ktere sifra (resp. jeji spravna implementace) vyzaduje. Jinak ti nezbyde nez (stejne jako mne) verit autorum softwaru, ze toto udelali. (Coz napriklad u openssl zjevne neni stoprocentni, jak nedavna historie ukazala.)
-
To K (neregistrovaný)
To K
jednoznačne áno má to zmysel najmä pri routeroch a sieťových komponentách, ktoré majú obmedzený zdroj entropie najmä ak sú tesne po reštarte a musia zvládať VPN, IPSEC a podobné veci, tam to zmysel má. A má to zmysel aj na počítači je to ako adidas čím víc pásikú tým viac adidas ;-) čím viac entropie tým lepšie.
