Daves svar genoptager det ganske pænt, men for at afklare lidt mere om den anden mulighed:

en ægte hardware tilfældig talgenerator bruger en fysisk entropikilde. En sådan entropikilde kan være kosmisk stråling, elektrisk støj, avanlanche-effekt fra en omvendt forspændt diode (eller BJT-transistor), chua-kredsløb osv. Jo mindre deterministisk entropikilden er, desto bedre er kvaliteten af ​​det tilfældige output. En ideel entropikilde ville være at bruge en kvantefysikeffekt eller noget, der umuligt kan modelleres med deterministiske ligninger.

En anden vigtig faktor med tilfældige talgeneratorer er, at entropikilden kun kan generere en begrænset mængde entropi pr. tidsenhed. Et godt eksempel er chua-kredsløbet: selvom det er ret tilfældigt, har det meget dårlig hastighed og kan umuligt bruges til virkelige applikationer.

I mange processorer / mikrocontrollere med indbyggede RNG'er er uret drift fra 2 til 4 ure, der bevidst er forkert synkroniseret, bruges. Derefter bruger de både analoge og digitale filtre til at randomisere endnu mere mønsteret og skifte resultatet ind i et register. At udføre en sådan filtrering kræver nogle få cyklusser, hvilket forklarer den mindste mængde cyklusser, der kræves på et givet ur, før den nyere værdi er tilgængelig.

Urets drift er ikke helt en kvanteeffekt, så det kunne modelleres, men det er tilfældigt nok, fordi det afhænger af mange parametre, såsom temperatur, siliciumproces, driftsfrekvens, elektrisk støj, baggrundsstråling osv.

I applikationer, hvor hardware-RNG ikke har tilstrækkelig kapacitet (f.eks. i meget krævende kryptografiske applikationer), er det ret almindeligt at bruge hardware-RNG som et frø til en pseudo-tilfældig talgenerator som f.eks. rand () -funktionen i sdtlib. Imidlertid giver en sådan anvendelse normalt en bedre implementering af rand (), som specifikt er designet til at køre fra et frø, som kan kasseres meget ofte med ægte tilfældige værdier. I nyere Intel-processor med integrerede hardware-RNG'er er den pseudo-tilfældige algoritmedel direkte integreret i silicium, så den udføres af hardware, hvilket giver meget høj tilfældig gennemstrømning.

Hvis du har noget imod rand () selve metoden, er det kun et metematisk udtryk, der er designet til at generere en stor nok mængde entropi. Stor nok er afhængig af applikationen: for kryptografiske nøglegenerationer kræves det, at tilfældigheden er af højere kvalitet end den tilfældighed, der kræves for en simpel tilfældig blanding i din yndlingsmusikafspiller. Det er indlysende, at jo højere kvaliteten af ​​det tilfældige output er, desto højere er beregningsomkostningerne for det tilfældige tal.

De operationer, der er involveret i et tilfældigt tal, ligner meget den, der er involveret i beregning af MD5-hash af en fil: de forsøger at bruge en slags bit lavineeffekt, så en enkelt bitændring i en frøværdi ændrer hele genereringsmønsteret. Som en sidebesked anbefaler jeg IKKE at bruge MD5 som en pseudo-tilfældig talgenerator; det var kun et eksempel. Det ville være både ineffektivt og ikke så tilfældigt, men pointen er der: hvis du fodrer den samme fil til en MD5-hasingalgoritme, får du altid den samme deterministiske output, stort set på samme måde som du altid ville få den samme output fra funktionen rand (), hvis du indtaster det samme frø, medmindre din implementering afhænger af nogle vilkårlige elementer, såsom aktuel tid.

Hovedforskellen er, at rand () biblioteksfunktionen er en pseudorandom talgenerator - givet en bestemt startværdi (frø), vil den altid producere den samme sekvens af tal.

På den anden side er RNG-periferienheden en ægte tilfældig talgenerator, og den vil producere ikke-gentagelige talrækkefølge.

De to emner, du skitserer, kan beskrives relativt let:

• 1: Du kan ikke generere tilfældige tal hurtigere end en gang hver 40 urcykler, så dette resulterer i 48MHz / 40 = ~ 1M prøve / s
• 2: Hardwaren indeholder en skærm, der kontrollerer hvert genereret nummer for mærkelig opførsel. F.eks. hvis du brugte temperatur som kilde og havde et meget stabilt temperaturmiljø, kunne det ske, at RNG igen ville generere de samme nummersekvenser (som en pseudo-tilfældig talgenerator ville gøre, hvis du starter med den samme frøværdi). Komponenten vil overvåge dette og give dig et signal, hvis RNG fungerer, som det forventes. Hvis du har brug for, at dine tal er "rigtigt" tilfældige, kan du overvåge dette flag for at se, om de virkelig er. Hvor nøjagtigt dette gøres, og hvordan RNG rent faktisk fungerer, er sandsynligvis angivet i den resterende tekst.

Antag at man designer en mekanisk roulettehjulsspinner, der aktiverer en motor i en vis periode, venter på at hjulet og kuglen skal hvile og observerer, hvilken lomme kuglen er i. Normalt efter hvert omdrejning skal bolden og hjul vil ende et lidt andet sted, og små variationer i boldens placering efter et spin kan gøre en enorm forskel i, hvor den ender på det næste spin. Selvom motoren altid får strøm i samme tidsperiode, vil lommen, hvor en kugle lander på et omdrejningstal, være uafhængig af, hvor den landede centrifugeringen før.

Antag nu dog, at en få af numrene har eller udvikler små fordybninger i dem, og motorens lejer udvikler flade pletter. Derefter ville nogle spins være tilfældige, men efter et spin, der resulterer i, at bolden lander i en depression og pejlingen på et fladt sted, kan det næste spin meget vel være forudindtaget mod at have det samme resultat som det sidste spin, hvor det skete. Hvis de fleste spins ikke samtidig rammer divot og fladt sted, påvirker deres eksistens sandsynligvis ikke tingene for meget. På den anden side, hvis en divot / flad combo tilfældigvis placeres lige så, at en bold der med rimelighed konsekvent lander på et sekund, og at en tilfældigvis placeres for at sende bolden tilbage til den første, så en ender med nogle ekstremt skæv opførsel.

Hvis næste spin efter landing på 4 og 23 er en 4, betyder det ikke nødvendigvis et problem. En 4 skal vises omkring 1/38 af tiden i den situation. Yderligere skal erhvervelse af tilfældige data bare fange lommenummeret, da der ikke vides noget nyttigt om, hvor ofte bolden skal hvile i forskellige dele af lommen. Ikke desto mindre kan det være nyttigt for alt, hvad der optager numrene, også at "observere", hvor i lommen bolden stopper og se efter eventuelle usædvanlige mønstre. Fordelingen af ​​placeringer kunne være skæv mod fronten eller bagud uden at indikere et problem, men hvis der er en smal stigning i fordelingen, kan det være grund til bekymring.

Hvis fortløbende aflæsninger fra en tilfældig generator er statistisk uafhængig , er det ikke svært at kompensere for bias (skønt den krævede tid ikke er bestemt). Hvis en generator imidlertid falder i en tilstand, hvor aflæsningerne ikke er uafhængige (f.eks. Den cykliske tilstand af hjulet ovenfor), bliver kompensation grundlæggende umulig - og dermed behovet for en hardware-RNG til at inkludere kredsløb til at detektere sådan adfærd.