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.