Názory k článku Hardwarový generátor náhodných čísel aneb náhoda z atomů

Není to trošku nefér porovnávat ten 50kB výstup z arduina s 30x menším souborem z /dev/random? Statistika mi nikdy nešla, ale myslím že u menšího vzorku bude vždycky větší korelace... O tom že třeba ten Monte Carlo test spošítá Pi podstatně hůř ani nemluvě.

Stačí kvedlat myší a dat je hned habaděj.

Zkusil jsem vygenerovat posloupnost přesně stejné délky jako v článku z /dev/random i /dev/urandom a je vidět, že na tom tyto generátory nejsou tak špatně. Myslím že podle tohoto testu nelze s jistotou říct, který z těchto generátorů je nejlepší.

Pro /dev/random
Entropy = 7.996967 bits per byte.
Optimum compression would reduce the size
of this 53943 byte file by 0 percent.
Chi square distribution for 53943 samples is 225.58, and randomly
would exceed this value 90.77 percent of the times.
Arithmetic mean value of data bytes is 128.1016 (127.5 = random).
Monte Carlo value for Pi is 3.138598443 (error 0.10 percent).
Serial correlation coefficient is -0.004200 (totally uncorrelated = 0.0).

Pro /dev/urandom
Entropy = 7.996040 bits per byte.
Optimum compression would reduce the size
of this 53943 byte file by 0 percent.
Chi square distribution for 53943 samples is 294.47, and randomly
would exceed this value 4.51 percent of the times.
Arithmetic mean value of data bytes is 127.4627 (127.5 = random).
Monte Carlo value for Pi is 3.139488320 (error 0.07 percent).
Serial correlation coefficient is -0.002909 (totally uncorrelated = 0.0).

len ci sa nepohybujes v statistickej chybe. urandom neblokuje ked nema dostatok entropie, takze lepsi vysledok by "nemal" dat (teda aspon ak mu naozaj dojde, mozno si len mal dostatocnu zasobu).

Ano, souhlasim s tou statistickou chybou. Ted uvedu co se stane, kdyz clovek ignoruje statistickou chybu a spatne interpretuje vysledky.

Kdyby neco vyslo v libovolnem testu POKAZDE jako 100% nahoda (a ne treba 99.998%) tak to znamena, ze se NEJEDNA o nahodna data, ale o data ktera presne vyhovuji dannemu testu. Takovych dat je malo, a tedy NEJSOU nahodna. Jako priklad bych zvolil ten aritmeticky prumer, ktery je v tech vypisech videt. Kdyby mi pri hodech kostkou vysel _vzdy_ prumer presne 3.5, tak to znamena, ze jeden z hodu (treba ten posledni) muzu dopocitat z ostatnich hodu. Tedy neni nahodny.

Podle mne je zasadni chybou toho programu, ze statistickou chybu nevypisuje a proto svadi k misinterpretaci vysledku.

Vysledok u mna:

~ $ time head -c 53943 /dev/random > temp/random.txt

real 334m50.805s
user 0m0.030s
sys 0m0.070s

$ ./ent ../../temp/ran­dom.txt
Entropy = 7.996672 bits per byte.

Optimum compression would reduce the size
of this 53943 byte file by 0 percent.

Chi square distribution for 53943 samples is 250.19, and randomly
would exceed this value 57.33 percent of the times.

Arithmetic mean value of data bytes is 127.5240 (127.5 = random).
Monte Carlo value for Pi is 3.148832036 (error 0.23 percent).
Serial correlation coefficient is -0.004329 (totally uncorrelated = 0.0).

je náhoda, že se dá složit CCCP?

Není, Soudruhu.
Musíte věřit.

Čest

Rychly a kvalitny generator moze byt zabudovany priamo v CPU.
Napriklad taka Via ho rovno ponuka pre radu x86 (x86_64) napriklad vo svojich CPU C7 alebo Nano.
Viac info tu - http://www.via.com.tw/en/initiatives/padlock/hardware.jsp
Via Padlock je podporovany uz dost dlho aj v Linux kerneli a modul napisal vas krajan.

Prosim berte to jako navrh na clanek. HW generatoru nahodnych cisel primo na desce jiz nekolik existuje, stejne tak podpora sifrovani (AES). Nejenom VIA, neco je i na ALIXech (geode). Myslim ze clanek o tom jak tyhle veci vyuzit v Linuxu, SSL, PGP a dalsich kryptografickych aplikacich by byl velmi prinosny.

Je rozdiel mat generator na doske a priamo v CPU... Co sa tyka architektury x86 VIA ho mala prva a okrem generatora ma v CPU aj AES a SHA(256).
Ak nejaky program pouziva kernel API, tak nahratie padlock modulov by malo stacit na to aby sa namiesto vstavanych funkcii pouzil HW v CPU.
Horsie je to s openSSL ktory pokial viem stale treba prekompilovat.

Viac info tu:

http://www.logix.cz/michal/doc/article.xp/padlock

Omyl, to s kostkami "ROOT" moze byt nahoda; keby to zlozilo tie iste kostky aj 100x, tak to moze byt nahoda. Problem je, ze u nahody si nikdy nemozeme byt isti...

Bral som to tak, narazal som na nieco ako http://v.gd/laBNJx a problematickost overenia, ci je nieco nahodne.

nejak nechapu jak si mam vysvetlit Chi kvadrat vysledky

u Arduina vyslo 0.01 a u random dat 10 coz podle toho co vsude pisou by mlo vychazet lip pro random protoze je bliz 50

Imho to chapes spravne. Cim blizsie k 50 je Chi kvadrat, tym lepsie. Hodnoty medzi 0 az 10 a 90 az 100, znamenaju, ze to asi nebude nahodne (je to v tabulke v clanku).

Navrhujem skusit brat posledne dva (respektive ak sumi i treti, tak tri) bity z prevodniku. Samozrejme namiesto do luftu zavesenej nozicky od prevodnika by som tam pripojil dajaku "antenu" typu radiator, hrnec, alebo podobne. Idealne by mohlo byt pripojit tu vec na mikrovlnku, ci blizko wifi ziarica.

Zaujimali by ma nejake dalsie testy s danou platformou a zberom random dat. Tieto podla chi kvadratu neboli moc presvedcivo nahodne...

PS: ak to ma clovek na stole a ma sa moznost hrat, ja by som to vyuzil. Ak je to uz poskladane a vratene, tak to nema asi zmysel opat poziciavat kvoli par vystupom z ent...

proc se bere z prevedeneho analogoveho signalu do digitalniho jen nejnizssi bit a ty se teprve skladaji do bytu?

Pretoze na najnizsom bite sa deje najviac fluktuacii...

Hm, az na to, ze lavarnd nema, krome nazvu, nic spolecneho s lavovou lampou.
Princip lavarnd, je webkamerka schovana v plechovce tak aby k ni nemohlo zadne svetlo. Tudiz veskery nasnimany obraz je sum CCD cipu a ten se pak dal pouziva jako zdroj nahodnych cisel.

Ako je to s nahodnostou zosileneho mikrofonoveho vstupu zvukovky, kam nie je nic zapojene? Teoreticky by to mal byt len sum zosilnovaca [= blizko bielemu sumu], nie?
Ano, mozu tam byt brumy na plosaku a podobne, ale zvukovka je dnes uz na skoro kazdej doske, netreba zatvarat kamerku do plechovky...

vetsina integrovanejch zvukovek ma pri nahravani ruchy v pozadi a to hlavne z ruznejch prechodu procesoru do uspornejch rezimu a podobne (vznikaj tam obrovsky zmeny v prudech - desitky amper) a ruznejch diskovejch operaci

Je to zajimave, ale na vstupu zvukovky zadna padesatka neni... alespon na vstupu moji zvukovky.

Ono se ani neni co divit, protoze vsechny sbernice i spinany zdroj jedou na vyrazne vyssich frekvencich.

Lavarnd ne, ale Lavarand ano.
http://cs.wikipedia.org/wiki/Gener%C3%A1tor_n%C3%A1hodn%C3%BDch_%C4%8D%C3%ADsel
http://en.wikipedia.org/wiki/Lavarand

Měl bych několik poznámek. Zaprvé generátor náhodných čísel v kernelu linuxu není nic moc ze statistického hlediska. Viděl jsem studii nějakých dvou maníků z Izraele a nedopadlo to pro něj zrovna dobře. Až ji od někud vydoluju, tak přidám link.
Za druhé nemusí se u HW generátorů provádět normalizace výstupních dat? Pokud vím tak ano. Jmenuje se to nějak jako Von Neumannova normalizace pokud si to dobře pamatuji.
Zatřetí i při realizaci HW RNG záleží na fyz. realizaci, protože při převodu na minární signál může dojít k vychýlení (prahové hodnoty při přepnutí mezi "0" a "1") a už to paradoxně není až zas tak náhodný generátor. Navíc není zas tak důležitá vydatnost, ale kvalita, protože se často provádí kryptografická expanze (prožene se to i několikrát přes SHAx apod.)pro získání dostatečné vydatnosti. Nejlíp je v tom ohlehledu asi FreeBSD protože používá Schneierův PRNG FORTUNA. Tedy jestli se nepletu.

... Viděl jsem studii nějakých dvou maníků z Izraele a nedopadlo to pro něj zrovna dobře ...

manici to neprezili ? ;-)

"Pokud budou sloupečky vyrovnané, získali jsme opravdu náhodný generátor."
Blbost! Sloupecky se budou zdat (budou relativne vyrovnane), jen kdyz nasamplujeme opravdu velky vzorek. Pri vzorku samplovanem v nejakem rozumnem case dostaneme prave takovy obrazek, jako ke kteremu je tato veta vztazena. Presneji receno precentuelni rozdil se bude snizovat, absolutni rozdil se bude zvysovat.

Predstavte si, ze samplujete ne 256 moznosti ale jen 6 moznosti - tedy hody kostkou. Budete povazovat za maximalni nahodu, jen kdyz hodem sesti kostkami hodite postupku? Urcite ne. Totez je se sloupeckama. Budou priblizne stejne velke, ale nebudou presne stejne velke. Kdyby byly, nebyl by zdroj nahodny.

Paráda, zrovna na jednom hadwarovém generátoru náhodných čísel pracuji. Jako zdroj signálu využívá šum operačního zesilovače. Není to zrovna nejideálnější řešení, Geiger-Müllera mi ale na škole nepovolili... :-)

Nie je problem urobit generator nahodnych cisiel zo sumu roznych suciastok. Problemom "skutocnych" nahodnych generatorov je to, aby sa nedali ovplyvnit ziadnymi vonkajsimi vplyvmi - teda ze sa znizi/zvysi teplota okolia o 20 stupnov (alebo svetlo sa dostakne k CCD kamere, zvuk k mikrofonu) a zrazu generator dava uplne ine vysledky, ktore uz nie su nahodne...

Vždyť ta data z HW generátoru tím Chi kvadrat testem neprošla! p-value vyšla 0.01%, to je velmi silný signál že NEJDE o náhodná data...!
To že entropie vyšla relativně OK neznamená nic víc, než že entropy test je velice slabý - což je ostatně známý fakt...

Nebylo by vůbec od věci, kdyby autor článku ta data dal k dispozici - přinejmenším pro mě by bylo velmi zajímavé se na ně podívat :) A nebylo by také od věci kdyby jich vygeneroval víc - 50k je docela málo. 10MB by bylo naprosto super, s tím už se dají udělat seriózní statistické testy :)

No tak na kvantové úrovni náhoda pokud vím existuje prakticky jistě. Nejenže platí Heisenbergův princip neurčitosti, ale bylo ukázáno že tento princip je velmi fundamentální: že dokonce neexistují žádné "skryté parametry" systému, jejichž výsledkem by byla ta zdánlivá náhodnost. Čili na kvantové úrovni myslím není co řešit, a navíc jevy na kvantové úrovni se vhodnými mechanismy velice rychle mohou přenést na makroskopická měřítka.

Co se týká házení kostkou: pokud s ní hodím rukou, tak s největší pravděpodobností výsledek nijak náhodný nebude. Ale, kdybych kostky zamíchal např. tak jak se to dělá při hře v kostky ... tak tam už bych si vsadil na to, že to bude opravdu velmi náhodné.

A pokud by navíc ta kostka byla vyrobena velice precizně, aby byla dokonale vyvážená a tato rovnováha nebyla narušena ani těmi "oky", a navíc by se s ní házelo pořádně (po předchozím "zamíchání") - pak v hodu kostkou nevidím problém.

Jinak, zda data jsou nebo nejsou náhodná lze otestovat relativně velice snadno, a je k tomu celá rozsáhlá sbírka statistických testů. Chi-kvadrat test je asi nejjednodušší z nich - a přitom už i tento vyloučil na 99.99% hladině významnosti že by ta data z té diody byla náhodná.

Interpretace Heisenbergova principu neurcitosti v klasicke fyzice je celkem osemetna a nemam odvahu se do ni poustet. Ale tak, jak se H.p.n. formuluje v kvantove mechanice, tak nerika nic jineho nez, ze pokud pripravite pokazdy stejny kvantovy stav a pak na nem budete merit polohu a hybnost (vzdycky znovu na tom puvodnim stavu), tak soucin kvadratickych odchylek polohy a hybnosti bude vetsi nez nejaka konstanta(nenu­lova,kladna). Jedna se tedy ciste o statisticke tvrzeni.
Jinak v kvantove mechanice castice skutecne nema zadnou presne definovanou polohu ani hybnost. Castice je reprezentovana vlnovou funkci, ktera v sobe obsahuje informace o statistickem rozdeleni polohy a hybnosti dane castice. Pri mereni pak dostaneme nejaky vysledek a pravdepodobnost, ze ho dostaneme, je dana prave temi rozdelenimi pravdepodobnosti.
Predpoklada se, ze ona nahodnost neni zpusobena pouze nedokonalosti naseho popisu sveta, ale ze ona nahodnost je skutecne fundamentalni vlastnosti sveta - takze vhodne pripraveny experiment (jako treba mereni spinu na castici ve "smisenem" stavu) umozni produkovat skutecne zcela nahodna data.

IMHO není potřeba nic tak složitého, postačí Geiger-Müllerův počítač a dostatečně radioaktivní vzorek. Radioaktivní rozpad je náhodný, respektive se střední četností danou určitými parametry, odchylka od tohoto středu je opravdu náhodná.

Neda mi to, abych hlavne pro zasmati neuvedl odkaz na nejvic cool generator nahody, ktery jsem kdy videl :-)

http://gamesbyemail.com/News/DiceOMatic

Zdravím všechny
rád bych použil externí HW generátor pro OpenSSL (generování priv.klíčů)
Může dát někdo tip, odkaz kde bude už postup jak na to? ..koukal jsem, že je asi nutné rekompilovat openssl...
Případně i doporučit nějaký levný HW generátor (ideálně jako USB dongle).