La casualità di von Neumann tra virgolette non è più applicabile?


25

Qualcuno ha detto quanto segue:

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Questo significa sempre che non puoi generare veri numeri casuali con un solo computer. E ha detto che quando i computer avevano le dimensioni equivalenti di un singolo microprocessore Intel 8080 (~ 6000 valvole). I computer sono diventati più complessi e credo che l'affermazione di von Von Neumann potrebbe non essere più vera. Considera che un algoritmo solo software implementato è impossibile. Funzionano su hardware fisico. I veri generatori di numeri casuali e le loro fonti di entropia sono anch'essi fatti di hardware.

Questo frammento Java inserito in un ciclo:

      file.writeByte((byte) (System.nanoTime() & 0xff));

posso creare un file di dati che ho rappresentato come immagine:

nanoimage

Puoi vedere la struttura, ma anche con molta casualità. La cosa interessante è che questo file PNG ha una dimensione di 232 KB, ma contiene 250.000 pixel in scala di grigi. Il livello di compressione PNG era massimo. Questo è solo un rapporto di compressione del 7%, vale a dire. abbastanza non comprimibile. La cosa interessante è anche che il file è unico. Ogni generazione di questo file ha uno schema leggermente diverso e ha una comprimibilità del ~ 7% simile. Lo sottolineo poiché è fondamentale per il mio argomento. Entropia di ~ 7 bit / byte. Ciò si ridurrà ovviamente con l'uso di un algoritmo di compressione più forte. Ma non ridurre a nulla vicino a 0 bit / byte. Un'impressione migliore può essere ottenuta prendendo l'immagine sopra e sostituendo la sua mappa dei colori con una casuale:

nanoimage randomizzato

La maggior parte della struttura (nella metà superiore) scompare in quanto erano solo sequenze di valori simili ma leggermente diversi. È una vera fonte di entropia creata semplicemente eseguendo un programma Java su un sistema operativo multi-acquisizione? Non un generatore di numeri casuali distribuito uniformemente, ma la fonte entropica per uno? Una fonte entropica costruita con software in esecuzione su hardware fisico che sembra essere un PC.

Supplemental

Per confermare che ogni immagine genera una nuova entropia senza uno schema fisso comune a tutti, sono state generate 10 immagini consecutive. Questi sono stati quindi concatenati e compressi con l'archiviatore più potente che riesco a compilare (paq8px). Questo processo eliminerà tutti i dati comuni, inclusa la correlazione automatica, lasciando solo le modifiche / entropia.

Il file concatenato è stato compresso al ~ 66%, il che porta a una velocità di entropia di ~ 5,3 bit / byte o 10,5 Mbit / immagine. Una sorprendente quantità di entropia

Supplemento 2

Ci sono stati commenti negativi sul fatto che la mia entropia con la metodologia del test di compressione è difettosa, dando solo una stima libera del limite superiore. Quindi ora ho eseguito il file concatenato attraverso il test di valutazione dell'entropia crittografica ufficiale del NIST, SP800-90B_EntropyAssessment . Questo è buono come si ottiene per la misurazione dell'entropia non IID. Questo è il rapporto (scusate se questa domanda si sta allungando, ma il problema è complesso): -

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

Il risultato è che NIST ritiene di aver generato 5,6 bit / byte di entropia. La mia stima della compressione fai-da-te lo mette a 5,3 bit / byte, leggermente più conservativo.

-> Le prove sembrano supportare l'idea che un computer che esegue software può generare vera entropia. E che von Neumann aveva torto (ma forse corretto per il suo tempo).


Offro i seguenti riferimenti che potrebbero supportare la mia richiesta:

Esistono modelli stocastici di non determinismo nel tasso di esecuzione del programma?

Analisi WCET di sistemi probabilistici duri in tempo reale

Esiste un algoritmo software in grado di generare un modello di caos non deterministico? e la rilevanza degli effetti caotici.

Parallelamente al principio di incertezza entropica quantistica

Il blog di Aleksey Shipilёv sul comportamento caotico di nanoTime (). La sua trama sparsa non è diversa dalla mia.


47
Penso che stai sbagliando "Non riesco a vedere uno schema" / casualità quotidiana con casualità matematica / stocastica.
Raffaello

3
@Raphael, io no. Gli algoritmi di compressione matematica lo fanno. E che senso hanno i sistemi operativi in ​​tempo reale se tutto il software è sempre deterministico? Sto solo chiedendo del determinismo in termini di bit.
Paul Uszak,

16
Ti stai unendo "su un computer" e "con mezzi deterministici".
user253751

24
Il tuo problema fondamentale qui è che inizi da "Non capisco come viene generato questo schema" e concludi "nessuno può capire come viene generato questo schema". Questo non è giusto e dato il tuo profilo SE hai sicuramente abbastanza familiarità con la crittografia per sapere che non segue. È facile ideare un sistema che non si può rompere, ma la vera sfida è escogitare un sistema che altri non possano rompere.
Gilles 'SO-smetti di essere malvagio' il

4
Penso che la maggior parte delle definizioni di "deterministico" escluderebbe algoritmi che chiamano System.nanoTime().
bmm6o

Risposte:


75

Solo perché non riesci a vedere uno schema non significa che non esiste uno schema. Solo perché un algoritmo di compressione non riesce a trovare un pattern non significa che non esiste alcun pattern. Gli algoritmi di compressione non sono proiettili d'argento che possono magicamente misurare la vera entropia di una fonte; tutto ciò che ti danno è un limite superiore alla quantità di entropia. (Allo stesso modo, il test NIST ti dà anche solo un limite superiore.) Il caos non è casualità.

Ci vuole un'analisi e un esame più dettagliati per iniziare ad avere una certa fiducia nella qualità della casualità ottenuta in questo modo.

Ci sono ragioni per pensare che probabilmente possiamo ottenere una certa casualità sfruttando il jitter del clock e la deriva tra due clock hardware , ma è delicato e complicato, quindi devi stare attento. Non consiglierei di provare a implementare il tuo. Invece, suggerirei di utilizzare una fonte di entropia di alta qualità (di solito implementata nella maggior parte dei sistemi operativi moderni). Per maggiori dettagli, vedi anche Wikipedia , hasged e /crypto//q/48302/351 (di cui sembra che tu sia già a conoscenza).

Infine, un commento sul tuo apri:

"Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato".

Questo significa sempre che non puoi generare veri numeri casuali con un solo computer.

No, non è così che di solito viene preso, e non è quello che sta dicendo. Sta dicendo che non puoi generare veri numeri casuali con mezzi deterministici . La possibilità di farlo su un computer dipende dal fatto che il computer sia deterministico o meno. Se il computer è deterministico o il tuo programma utilizza solo operazioni deterministiche, non puoi. Tuttavia, molti computer contengono elementi non deterministici e, se il programma li utilizza, è necessaria un'analisi più dettagliata prima di poter decidere se possono essere utilizzati per generare numeri casuali. Nel tuo caso nanoTime()non è deterministico.


6
Per espandersi sul punto dell'algoritmo di compressione, PNG, come la maggior parte degli algoritmi di compressione, cerca modelli nei dati. Un algoritmo che cerca schemi nelle modifiche ai dati probabilmente comprime l'immagine di esempio abbastanza bene.
Segna il

1
@ Mark - effettivamente, PNG non analizzare i criteri di modifiche (utilizza compressione deflate applicata alla differenza tra il valore di pixel effettivo e l'uscita di uno di una serie di euristiche previsione che si basano sui tipi di cambiamento già viste nell'immagine) , tuttavia l'analisi eseguita è piuttosto semplicistica in quanto è stata progettata in modo tale da poter essere eseguita in modo efficiente su dispositivi integrati negli anni '90. Una domanda più interessante sarebbe quanto accurato potrebbe essere un algoritmo di compressione con perdita di dati, ad esempio qual è l'errore RMS di JPEG o un qualche tipo di compressione frattale applicata all'immagine?
Jules,

3
@Jules: Ciò che conta non è che PNG sia semplicistico, ma piuttosto che sia progettato per comprimere i tipi di motivi che potrebbero apparire in molti tipi di immagini. Se si dovesse scattare una foto tipica, ad esempio 123x234 pixel e cambiarla in 234x123 mantenendo i pixel nello stesso ordine (quindi la prima riga della nuova immagine conteneva 123 pixel dalla riga superiore della vecchia, più 111 pixel della seconda riga, la riga successiva della nuova immagine conteneva gli ultimi 12 pixel della seconda riga originale, tutta la terza riga originale e 99 della quarta, ecc. PNG avrebbe ...
supercat

1
... probabilmente non comprimerà l'immagine risultante quasi come l'originale poiché non ci sarebbe più la stessa relazione spaziale tra le righe, nonostante il fatto che la seconda immagine contenga esattamente gli stessi pixel, nello stesso ordine esatto, come primo.
supercat

100

Se stai usando una fonte hardware di entropia / casualità, non stai "tentando di generare casualità con mezzi deterministici " (la mia enfasi). Se non stai usando alcuna fonte hardware di entropia / casualità, un computer più potente significa solo che puoi commettere più peccati al secondo.


I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat .
DW

20

Ho sempre capito che la citazione significa che un algoritmo deterministico ha una quantità fissa di entropia e sebbene l'output possa apparire "casuale" non può contenere più entropia di quanto gli input forniscano. Da questo punto di vista, vediamo che il tuo algoritmo contrabbanda nell'entropia attraverso System.nanoTime()- la maggior parte delle definizioni di un algoritmo "deterministico" non consentirebbe di chiamare questa funzione.

La citazione - mentre pithy - è essenzialmente una tautologia. Non c'è nulla da confutare e non è possibile alcuna evoluzione dell'hardware che possa renderlo non più vero. Non si tratta di hardware, si tratta della definizione di un algoritmo deterministico. Sta semplicemente osservando che determinismo e casualità sono incompatibili. Per qualsiasi algoritmo deterministico, il suo intero comportamento è previsto dalle sue condizioni iniziali. Se pensi di aver trovato un'eccezione, stai fraintendendo cosa significa essere deterministici.

È vero che un processo in esecuzione su un computer condiviso con una serie complessa di cache e che riceve vari input di rete e hardware ha accesso a molta più entropia rispetto a uno in esecuzione su hardware semplice, isolato e dedicato. Ma se quel processo accede a quell'entropia non è più deterministico e quindi la citazione non si applica.


In caso di riflessione (non di tipo Java) non sono sicuro che sia richiesto nanoTime (). Questo era solo un cronometro ersatz per tracciare l'avanzamento del ciclo che lo circonda. Se nanoTime () fosse rimosso, credo che la velocità di esecuzione del loop stesso (senza chiamate dirette all'hardware) sarebbe anche non deterministica in quanto software che interagisce ancora con l'ambiente del computer. Questa è l'intera base della programmazione in tempo reale su kit incorporato. Sono abbastanza convinto che la citazione di von Neumann non sia più applicabile a un computer moderno.
Paul Uszak,

1
@PaulUszak Quante volte devo dire questo? Von Neumann afferma che non è possibile generare numeri casuali in modo deterministico. Continui a dire che Von Neumann ha torto perché potresti usare il non determinismo. È come se affermassi ripetutamente che l'affermazione "ci vuole molto tempo per camminare da Parigi a Berlino" non si applica nel mondo moderno perché puoi volare tra quelle due città. E allora? La citazione riguarda il camminare e ciò richiede ancora molto tempo. La citazione di von Neumann riguarda i sistemi deterministici e non possono ancora operare in modo casuale.
David Richerby,

1
@PaulUszak È letteralmente impossibile. Se pensi di avere un algoritmo deterministico il cui comportamento non è determinato dai suoi input, si tratta solo di identificare dove viene introdotta l'entropia.
bmm6o,

18

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Quando interpreti "vivere in uno stato di peccato" come "fare una sciocchezza", allora è perfettamente giusto.

Quello che hai fatto è stato usare un metodo piuttosto lento System.nanoTime()per generare casualità piuttosto deboli. Ne hai misurato un po '

... tasso di entropia di ~ 5,3 bit / byte ...

ma questo è solo il limite superiore. Tutto quello che puoi mai ottenere è un limite superiore. La vera entropia può essere ordini di grandezza più piccoli.

Prova invece a riempire l'array usando un hash crittografico come MD5. Calcola una sequenza come md5(0), md5(1), ...(da ogni valore preso uno o più byte, questo non ha importanza). Non otterrai alcuna compressione (sì, MD5 è rotto, ma comunque abbastanza buono da produrre dati incomprimibili).

Possiamo dire che non c'è affatto entropia, eppure misurereste 8 bit / byte.

Quando hai davvero bisogno di qualcosa di casuale, non solo devi usare una fonte HW, ma devi anche conoscere un limite sicuramente inferiore a quanta entropia produce davvero. Mentre molto probabilmente c'è una certa casualità nanoTime(), non sono a conoscenza di alcun limite inferiore non banale.

Quando hai bisogno di casualità per la crittografia, devi davvero ricorrere a qualcosa fornito dal tuo sistema operativo, dalla tua lingua o da una buona libreria. Tali fornitori raccolgono entropia da più fonti e / o HW dedicati e un bel po 'di lavoro è stato dedicato a tali stime entropiche.

Nota che di solito non hai bisogno di entropia. Un buon PRNG (deterministico) inizializzato con pochi byte casuali è utilizzabile per la crittografia, e quindi anche per tutto il resto.


4
@PaulUszak Certo, un PRNG deterministico non può essere utilizzato come OTP. Ma OTP è un caso molto speciale in quanto per definizione richiede una chiave veramente casuale. AFAIK per qualsiasi altra cosa, è sufficiente un PRNG sicuro con seeding casuale (il seed deve avere ad esempio 128 o 256 bit di entropia, a seconda del livello di sicurezza richiesto).
maaartinus,

3
"Quando hai davvero bisogno di qualcosa di casuale" → In pratica non hai mai bisogno della vera casualità. Piuttosto, hai bisogno di una mancanza di correlazione. La vera casualità è una forte garanzia, ma sostanzialmente ogni caso è altrettanto soddisfatto da un moderno CSPRNG e da un seme imprevedibile.
Veedrac,

3
@maaartinus Non mi stai prendendo abbastanza. Sto dicendo che non hai bisogno di veri semi casuali, hai solo bisogno di semi non correlati imprevedibili.
Veedrac,

6
Ad esempio, ho creato un file di testo con 1 milione di numeri sequenziali. gzipè stato in grado di ottenere una compressione del 63%, anche se non c'è quasi entropia. Poteva solo rilevare le ripetizioni come999919999299993...
Barmar,

6
@PaulUszak Quello era il mio punto: il rapporto di compressione non è un buon indicatore di entropia, indica se il particolare algoritmo di compressione è in grado di rilevare il tipo di pattern che contengono i tuoi dati.
Barmar,

14

Ho pensato di entrare nel significato di "casuale". La maggior parte delle risposte qui parla dell'output di processi casuali , rispetto all'output di processi deterministici. Questo è un significato perfettamente buono di "casuale", ma non è l'unico.

Un problema con l'output di processi casuali è che sono difficili da distinguere dagli output di processi deterministici: non contengono un "record" di quanto casuale sia stata la loro fonte. Un esempio estremo di questo è un famoso fumetto XKCD in cui ritorna sempre un generatore di numeri casuali 4, con un commento in codice che afferma che è casuale perché proviene da un tiro di dado.

Un approccio alternativo alla definizione di "casualità", chiamato complessità di Kolmogorov , si basa sui dati stessi, indipendentemente da come sono stati generati. La complessità di Kolmogorov di alcuni dati (ad esempio una sequenza di numeri) è la lunghezza del programma per computer più breve che emette tali dati: i dati sono "più casuali" se hanno una complessità di Kolmogorov più alta.

L'uso di algoritmi di compressione come PNG e il confronto della lunghezza prima e dopo la compressione è simile all'idea della complessità di Kolmogorov. Tuttavia, la complessità di Kolmogorov consente di codificare i dati come programma in qualsiasi linguaggio di programmazione completo di Turing, piuttosto che in un formato limitato come PNG; "decomprimere" tali codifiche (programmi) viene eseguita eseguendole, il che può richiedere una quantità arbitraria di tempo e memoria (ad es. più di quanto sia disponibile nel nostro universo impertinente).

Il teorema di Rice ci dice che non possiamo, in generale, distinguere tra programmi che si ripetono per sempre e programmi che producono i nostri dati. Quindi è molto difficile trovare la complessità di Kolmogorov di alcuni dati: se scriviamo un programma che genera tali dati, potrebbe effettivamente esserci un programma più breve (cioè una complessità inferiore), ma non lo individuiamo perché non potremmo distinguilo da un ciclo infinito. La complessità di Kolmogorov è quindi incontestabile, sebbene se conoscessimo i numeri di Busy-Beaver potremmo calcolarli usando quelli per limitare il tempo che controlliamo ogni programma.

Nel caso dei tuoi dati di esempio, per trovare la sua complessità di Kolmogorov (cioè "casualità intrinseca") avremmo bisogno di trovare il programma deterministico più breve che emetta la stessa sequenza di byte e prendere la sua lunghezza.

Ora possiamo rispondere alla tua domanda dal punto di vista della complessità di Kolmogorov e scopriamo che la citazione è corretta: non possiamo generare numeri casuali (elevata complessità di Kolmogorov) con mezzi deterministici.

Perchè no? Immaginiamo di scrivere un piccolo programma per computer e di usarlo per generare una sequenza di numeri casuali. È necessario applicare una delle seguenti situazioni:

  • Generiamo una grande quantità di output. Tuttavia, poiché sappiamo che questo output è generato da un piccolo programma, l'output (per definizione) ha una bassa complessità di Kolmogorov, e quindi non è "casuale" in questo senso.
  • Generiamo così pochi numeri che scrivere tutti li richiederebbe più o meno gli stessi bit che scrivere il nostro programma di generazione breve. In questo caso, i numeri sono relativamente incomprimibili, il che indica che sono abbastanza casuali nel senso di Kolmogorov. Tuttavia, poiché la quantità di output è paragonabile a ciò che abbiamo inserito (il codice sorgente per il programma), è giusto dire che il programma non ha "generato" la casualità, lo abbiamo fatto scegliendo quel programma. Dopotutto, in questo caso il nostro programma di generazione potrebbe anche essere stato un elenco di questi numeri esatti (ad es print([...]).).

In entrambi i casi, non stiamo "generando" una casualità maggiore di quella che inseriamo (la "casualità" del codice sorgente del nostro programma di generazione). Potremmo provare a aggirare questo problema usando un programma di generazione più lungo, per evitare che l'output abbia un generatore corto, ma ci sono solo due modi per farlo:

  • "Gonfia" sistematicamente il codice in qualche modo. Tuttavia, alla complessità di Kolmogorov non interessa il particolare programma che abbiamo usato per generare i dati: si preoccupa solo di qualsiasi programma di generazione sia il più piccolo. Il gonfiore sistematico non aggiunge complessità di Kolmogorov, poiché tali schemi nel codice possono essere generati da soli con una quantità molto piccola di codice. Ad esempio, se prendiamo run(shortGenerator)e aggiungiamo un intero carico di gonfiamento sistematico da ottenere run(bloatedGenerator), esiste ancora un breve generatore del modulo run(addBloat(shortGenerator)).
  • Aggiungi bloat in modo non sistematico , cioè senza alcun pattern, in modo che una addBloatfunzione debba finire per essere gonfiata come il codice stesso. Tuttavia, essere così privo di schemi è esattamente ciò che rende qualcosa di casuale (elevata complessità di Kolmogorov). Quindi gonfiore del programma di generazione in questo modo non aumentare la casualità (Kolmogorov complessità) dell'uscita, ma anche aumenta la quantità di casualità (Kolmogorov complessità) che dobbiamo fornire sotto forma di codice sorgente. Quindi siamo ancora noi a fornire la "casualità" e non il programma. Nell'esempio sopra di solo scrivere print([...]), aggiungere un bloat non sistematico equivale a scrivere più numeri "casuali" in quell'elenco hardcoded.

"trova il programma deterministico più breve che emette la stessa sequenza di byte" - questo è l'intero punto del mio argomento, punto esclamativo. Non puoi ripetere questa immagine. È unico ogni volta. Il modello è il risultato dell'interazione di Java, JVM, sistema operativo, CPU + cache, disco rigido, musica Trance che stavo trasmettendo in streaming che consuma cicli CPU / RAM e tutto il resto. Il modello deriva semplicemente dall'unica riga del codice Java all'interno di un ciclo for / next. Una parte significativa dell'entropia viene dai circuiti hardware sottostanti. Non può essere codificato.
Paul Uszak,

@PaulUszak La complessità di Kolmogorov misura la "casualità" di un valore particolare , come la prima immagine che hai pubblicato; o la seconda immagine che hai pubblicato; o un'istantanea di questa pagina HTML; ecc. Se ti interessa il processo che ha generato un'immagine (deterministica o no), allora altre misure come le informazioni di Shannon sarebbero più adatte; Ho appena visto che nessun'altra risposta ha menzionato la complessità di Kolmogorov. Sono entrambi metodi utili, poiché ci dicono cose diverse.
Warbo

@PaulUszak Considera il test che hai fatto comprimendo queste immagini come file PNG e confrontando le dimensioni del file. Quando decomprimi un PNG, ottieni esattamente la stessa immagine con cui hai iniziato; è deterministico; tu non ottiene un diverso, un'immagine casuale. Ciò rende inutile il test di compressione? Affatto! La complessità di Kolmogorov è come una versione estrema del tuo test PNG: anziché comprimere in un file PNG, comprimiamo in un programma (deterministico) per computer. Questi possono diventare veramente piccoli, pur essendo in grado di riprodurre tutti i dati originali.
Warbo

6
@PaulUszak Sulla base del tuo commento sembra che tu abbia già realizzato tutto il necessario per provare la citazione: non hai usato mezzi deterministici per creare il modello, perché fai affidamento sull'entropia che tu o il mondo esterno (hardware e server di rete da cui stai trasmettendo, contenuti dello stream, ecc.) è stato introdotto nel tuo sistema. Se controllare o meno gli ultimi otto bit di misurazioni del tempo in nanosecondi presi in un ciclo è un buon modo per raccogliere quell'entropia è una domanda separata su cui molte risposte vengono bloccate, ma è un argomento separato.
mtraceur,

7

La compressione non è un test accurato di casualità, né guarda un'immagine e dice "sembra casuale".

La casualità è testata con metodi empirici . Esistono infatti suite di software / algoritmi appositamente progettati per testare la casualità, ad esempio TestU01 e i test Diehard .

Inoltre, la tua immagine è in realtà una stringa 1D di numero mappata su uno spazio, e quindi non è una buona rappresentazione di alcuni schemi che possono apparire.

Se dovessi esaminare l'immagine pixel per pixel, molto probabilmente troverai molti brevi schemi di valore crescente prima di un calo improvviso. Se dovessi creare un grafico con il valore x come numero di campione e il valore y come valore ottenuto dalla funzione 'random', molto probabilmente scopriresti che i tuoi dati sembrano effettivamente un'onda a dente di sega:

Sawtooth Wave

Questo è il modello creato da valori che aumentano sotto l'aritmetica modulare (di cui il tuo calcolo è un esempio di: tempo che aumenta a un ritmo quasi costante e & 0xFFazione come mod 256).


Sembra che tu abbia sbagliato serie di test. Tutti i test sono test di superamento / fallimento della casualità. Non misurano l'entropia che è il nocciolo di questa domanda. La compressione è una misura di entropia totalmente valida per dati non IID (vedere misure di entropia NIST). In realtà è uno dei pochi che può essere ragionevolmente implementato senza dottorati in programmazione e matematica. Anche se hai ragione sul dente di sega. È così, ma i denti non sono deterministicamente casuali, non regolari come hai mostrato. Da qui l'entropia.
Paul Uszak,

2
@PaulUszak Questa misura ha senso se dipende dall'algoritmo di compressione?
Kutschkem,

@kutschkem WEll è una delle misure entropiche standard in NIST SP 800-90B. È anche facile da fare. In quale altro modo è possibile misurare l'entropia non IID? E gli alghe di compressione sono asintotici a un limite inferiore, quindi la divisione per 2. La formula di Shannon non funziona qui.
Paul Uszak,

3
@PaulUszak: per scopi crittografici, dovremmo presumere che il metodo di generazione sia noto a un utente malintenzionato. Conoscere il metodo con cui questi dati sono stati generati consente quasi certamente di scrivere un algoritmo di compressione che fa meglio di PNG o qualunque approccio faccia il test NIST, entrambi i quali non assumono nulla (o, nel caso di PNG, niente che sia effettivamente corretto) sulla fonte dei dati.
Jules,

5

Stai confondendo il concetto di numeri casuali da "numeri che sembrano essere casuali".

Per capire la citazione di von Neumann, dobbiamo capire cosa significa "generare numeri casuali". La risposta di Warbo collega un eccellente XKCD a questo scopo: Fumetto XKCD

Quando parliamo di numeri casuali, non stiamo parlando dei valori stessi. Ovviamente un 4 non è più casuale di un 3. Stiamo parlando della capacità di una terza parte di prevedere questo valore meglio di una casualità. Un numero casuale è uno che non è prevedibile. A volte aggiungeremo condizioni a questo. Un generatore di numeri pseudo-casuali sicuro (CSPRNG) crittograficamente sicuro genera numeri che non possono essere previsti bettr che probabilità casuali se un attaccante non conosce il seme / chiave, ma se stiamo parlando di numeri veramente casuali (non pseudo-casuali), di solito è definito come un numero che non è prevedibile, anche con una conoscenza completa del sistema, comprese eventuali chiavi.

Ora, il tuo esempio, come molti hanno sottolineato, non è deterministico. Il programma non specifica da quale valore esce System.nanoTime(). Quindi non è nella stessa classe dell'utilizzo di un CSPRNG per generare numeri pseudo casuali. Il primo può essere non deterministico mentre il secondo è deterministico se il valore della chiave è deterministico. Il primo contiene operazioni che non sono definite per avere valori deterministici.

Tuttavia, noterai che ho detto che potrebbe non essere deterministico. Tenere presente che System.nanoTime()non è progettato per fornire valori a questo scopo. Può essere o non essere sufficientemente non deterministico. Un'applicazione potrebbe regolare l'orologio di sistema in modo tale che tutte le chiamate si System.nanoTime()verifichino su multipli di 256 nanosecondi (o chiusura). Oppure potresti lavorare in Javascript, dove i recenti exploit di Spectre hanno portato i principali browser a ridurre intenzionalmente la risoluzione dei loro timer. In questi casi, i tuoi "numeri casuali" possono diventare altamente prevedibili in ambienti che non avevi pianificato.

  • Quindi generare numeri casuali con processi deterministici ... peccato.
  • Generazione di numeri casuali con hardware casuale dedicato ... non peccato.
  • Generare numeri casuali con aspetti non deterministici dei computer ... forse peccato.

Tutto dipende da ciò che intendi. Se stai crittografando le tue lettere d'amore a Sponge Bob in modo che tua sorella non possa leggerle, le richieste poste sui tuoi cosiddetti numeri casuali sono piuttosto basse. System.nanoTime()usato come hai fatto è probabilmente abbastanza buono. Se stai proteggendo i segreti nucleari da uno stato straniero avanzato che li sta attivamente cercando, potresti prendere in considerazione l'uso di hardware progettato per essere all'altezza della sfida.


4

Non credo che tu abbia capito l'affermazione. Il punto è che se esiste una procedura deterministica per generare una serie di numeri "casuali" (o qualcosa del genere), trovare il modello è semplicemente il compito di trovare questa procedura!

Quindi, esiste sempre un metodo deterministico per prevedere il numero intero successivo. Questo è esattamente ciò che non ci aspettiamo che accada se assumiamo casualità!

Qualsiasi determinismo sufficientemente complesso è indistinguibile dalla stocastica.

- Dalla pagina utente di Wrzlprmft

Quindi, anche se qualcosa sembra casuale, perché mai dovremmo modellarlo come 'casuale' se avessimo una procedura deterministica per generarlo?

Questo, penso, è il problema chiave. Hai mostrato solo una qualche forma di indistinguibilità del PRNG e "vera casualità".

Tuttavia, il fatto che questi concetti siano uguali non segue. In particolare, la casualità è un concetto matematico e teorico . Abbiamo già dimostrato sopra, che in teoria, considerare il PRNG come "vera casualità" porta a una contraddizione. Quindi, non possono essere uguali.


1
Err, sei sicuro di aver capito quella citazione? Sembri contraddirlo tu stesso ..?
Paul Uszak,

Sono io? Puoi chiarire? Intendevo dire che se desideri trattare qualcosa come casuale, generarlo in modo deterministico è inutile, anche se qualcun altro non riesce a vedere la differenza.
Lucertola discreta

2
@PaulUszak Sostieni che, poiché qualcosa ti sembra stocastico, è casuale. Ma in realtà, solo perché qualcosa sembra stocastico non significa che sia casuale - potrebbe anche essere un processo deterministico sufficientemente complesso.
Gilles 'SO-smetti di essere malvagio' il

O(n2)

3

Penso che altri lo abbiano già sottolineato, ma non era questo che sottolinea, quindi vorrei aggiungere anche alla discussione.

Come altri hanno già sottolineato, c'è il problema di misurare l'entropia. Gli algoritmi di compressione possono dirti qualcosa, ma sono indipendenti dalla fonte. Dato che sai di più su come sono stati generati i dati, probabilmente potresti costruire un algoritmo molto migliore per comprimerlo, e ciò significa che l'entropia reale è molto più bassa.

Inoltre, stai in qualche modo confondendo i significati delle frasi "sul computer" e "deterministico". È certamente possibile eseguire operazioni non deterministiche sul computer.

Inoltre, in effetti, l' hai appena fatto , ma non è così evidente a prima vista.

Un tipico algoritmo deterministico per una generazione di numeri casuali è cioè. PRNG come generatore congruenziale lineare. Sono di stato. Lo stato interno significa meno entropia poiché lo stato successivo è determinato dal precedente. Non approfondirò questo, probabilmente è ovvio per te. Il punto importante è che l'algoritmo completamente deterministico dipende solo dallo stato precedente, qualunque esso sia.

Ora guarda il tuo algoritmo. Su cosa si basa? Quanto stato hai? È deterministico?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Ignoriamo file.writee qualsiasi problema di svuotamento dei buffer, in attesa di I / O (hai provato ad aggiungere un forte rumore sui cavi del disco rigido per un momento? No? Ehi, potresti farlo. Ehi, non è deterministico allora! :)) e concentriamoci sulla fonte, è più importante.

Il tempo è una specie di stato. Varia, ma la maggior parte è la stessa. Ecco perché hai tentato di aggirarlo e hai impiegato & 0xFF per eliminare la maggior parte dello stato. Ma non hai lasciato cadere tutto, alcuni stati della lettura precedente potrebbero passare a quello successivo, quindi non è certamente del tutto non deterministico *)

Ma non ci interessa. Per "provare" che la citazione è sbagliata:

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Devi dimostrarlo con mezzi deterministici.
Ciò che ci interessa è: il tuo algo è sicuramente del tutto deterministico ?

..e è ovvio che non lo è.

  System.nanoTime() & 0xff

Questa è una misurazione del tempo. Tempo e misurazione . La parte di misurazione può renderla deterministica, se il valore viene memorizzato nella cache. Suppongo che non lo sia, altrimenti questa funzione non avrebbe senso. Quindi, se viene letto al volo dalla fonte, abbiamo un valore basato sul tempo. Dato che ( suppongo di nuovo ) non l'hai eseguito su un hardware dedicato a singola attività, a volte potresti avere il kick-switch di cambio di contesto. Anche se si disponesse di un hardware dedicato a singola attività, la misurazione del tempo potrebbe non essere deterministica, a causa delle variazioni di temperatura / umidità nella sorgente del tempo, dei tempi di clock del bus, ecc.

Sono totalmente d'accordo che sto esagerando qui. Le derive non saranno così grandi da avere un grande impatto (anche se per davvero nanotimepotrebbero essere). Ancora più importante, nanotimeè pensato per essere veloce. Non legge dalla fonte in tempo reale. Si basa sul conteggio interno delle istruzioni / del ciclo del processore. Questo è in realtà deterministico, se non si garantisce alcun cambio di contesto.

Il mio punto è che in realtà potrebbe essere molto difficile eseguire un algoritmo deterministico veramente al 100% se lo si basa sul tempo e non si ha il diritto di confutare quella citazione a meno che non si disponga di mezzi completamente deterministici.

*) È interessante notare che probabilmente potresti aumentare la casualità effettiva se vai nel modo più duro. Esegui & 0x01, bit per bit, e attendi il thread un tempo evidente, prima di leggere ogni bit. La generazione di dati in questo modo sarebbe ridicolmente lunga, ma in realtà direi che potrebbe essere considerata quasi casuale, IIF che stai eseguendo su non-RTOS e anche IFF in ogni "tempo evidente" è abbastanza alto da garantire che Il sistema operativo è andato in sospensione o è passato al contesto in un'altra attività.


2
NUNS

Qualcosa del genere era esattamente il mio punto dietro "[tu] potresti costruire un algoritmo [compressione] molto migliore"
quetzalcoatl

Non essere fissato sull'esatto valore 5.3. Indipendentemente da quanto meglio sia possibile creare un algo di compressione (non è possibile poiché ho usato uno dei migliori al mondo - paq8px), ciò che rimane incomprimibile è pura entropia. Questa è una delle principali definizioni di casualità. O stai suggerendo che qualcosa può essere compresso a zero byte? Gli appassionati di piccioni non sarebbero d'accordo.
Paul Uszak,

Lo 0xff è lì perché non puoi fare un buon piccy usando numeri interi a 64 bit. E se usi 0x01 devi scherzare con la gestione dei bit che non mi dava fastidio. È tutto. L'entropia del NIST e le mie misure suggeriscono comunque l'entropia nei bit più alti (~ 5 di essi).
Paul Uszak,

1
+1, e questa mi sembra la risposta migliore finora: l' unica fonte di entropia nella situazione di cui ci si chiede è proprio l'incoerenza nel tempo che passa tra ogni lettura dell'orologio ! E ciò deriva da un mix di dettagli come il funzionamento dello scheduler del sistema operativo e come funziona l'hardware e dettagli come ciò che l'utente ha fatto a quel sistema fino a quel momento che a sua volta influisce indirettamente su cose come ciò che è necessario programmare o per quanto tempo gli accessi hanno avuto a causa della frammentazione nel tempo o di ciò che era in swap / memoria / cache o quale attività di rete / ecc. era in corso.
mtraceur,

2

Penso che la risposta di cui hai bisogno inizi con questo commento che tu stesso hai fatto in risposta a un'altra risposta:

Il modello è il risultato dell'interazione di Java, JVM, sistema operativo, CPU + cache, disco rigido, musica Trance che stavo trasmettendo in streaming che consuma cicli CPU / RAM e tutto il resto. Il modello deriva semplicemente dall'unica riga del codice Java all'interno di un ciclo for / next. Una parte significativa dell'entropia viene dai circuiti hardware sottostanti.

Lo capisci già, penso: non hai usato mezzi deterministici per creare il modello.

Hai usato un computer, una parte non trascurabile di cui è deterministica, ma l'entropia proveniva da fonti esterne non deterministiche (o almeno non deterministiche per tutti gli scopi pratici al momento): tu o il mondo esterno che interagite con il computer (e, in misura minore, eventuali imperfezioni fisiche nell'hardware del computer che potrebbero influire sui tempi delle cose).

Questo, tra l'altro, è una grande parte di come i moderni sistemi operativi seminano i loro generatori di numeri casuali disponibili per i programmi: sfruttando l'entropia nelle interazioni con il suo hardware e l'utente che speriamo non siano prevedibili per un attaccante.

A proposito, l'entropia del mondo esterno è in realtà un problema che deve essere affrontato fino ad oggi nella crittografia altrimenti ben codificata: computer che hanno comportamenti prevedibiliall'avvio e durante il loro runtime, come quelli con memoria di sola lettura o che si avviano dalla rete e che hanno un ambiente di rete prevedibile (o non collegato a una rete o il carico di lavoro sulla rete è abbastanza basso da consegnare tutto all'interno un periodo di tempo affidabile) e che eseguono lo stesso insieme limitato di software con un comportamento approssimativamente coerente, potrebbero sovrastimare gravemente l'entropia che stanno ottenendo da questi componenti considerati imprevedibili e finire per generare numeri molto più prevedibili di quanto ti aspetteresti su una tipica postazione di lavoro che sta facendo ogni sorta di altre cose per te (streaming di musica, sincronizzazione con dropbox, qualunque cosa) in background.

Penso che la maggior parte delle risposte si stiano concentrando sul fatto che controllare gli ultimi otto bit di misurazioni del tempo in nanosecondi prese in un ciclo sia un buon modo per raccogliere quell'entropia. Questa è una domanda molto importante a cui rispondere correttamente prima di usare il metodo nel tuo esempio come uno schema di generazione di numeri casuali in pratica , ma è una domanda separata da ciò che penso tu stia chiedendo.


0

Per aggiungere alle risposte precedenti, ecco un modo semplice di pensare a questa domanda.

Riguarda la differenza tra casuale e deterministico . Verremo da Von Neumann e da quello che stava dicendo in seguito.

Numeri casuali

Un vero generatore di numeri casuali non avrebbe alcun modello, nemmeno nascosto nello sfondo, che potremmo usare per prevedere il numero successivo data la sequenza finora. In un mondo ideale, potresti sapere tutto quello che c'è da sapere nell'universo fisico e sul sistema, nanosecondo per nanosecondo, e sarebbe comunque inutile provare a prevedere il prossimo numero prodotto.

Questo è un caso ideale: in termini pratici ci arriviamo mescolando insieme molte fonti che sono "approssimazioni non cattive" a casuali, o che sono veramente casuali, o che mescolano matematicamente le cose abbastanza da poter dimostrare matematicamente che si avvicinano molto a imprevedibili e mancanza di parzialità verso numeri o schemi specifici.

  • Le fonti "buone" sono cose simili all'attesa di un processo di decadimento radioattivo o di altro processo quantico intrinsecamente imprevedibile. Uscita da un semiconduttore sensibile al calore. Rumore casuale in un diodo o altro materiale elettrico. Contando i fotoni dal sole.

  • Mescolato in questo, possiamo anche aggiungere alcuni che consideriamo "non male" che aiutano in quanto non hanno alcuna connessione a questi: in attesa del prossimo clic del mouse o pacchetto di rete. Ultimo bit di microtime sulla scrittura del file successivo. Uscita di una funzione di generatore di numeri pseudocasuali "nota ma matematicamente piuttosto casuale". Entropia precedente da precedenti usi di numeri casuali.

Lo scopo qui è quello di ottenere un numero che non è ancora possibile prevedere , qualunque cosa nell'universo che conosci , ed è statisticamente più probabile che sia questo come quello, senza schemi, pregiudizi o prevedibilità matematicamente rilevabili e nessuna correlazione con un evento che potrebbe essere monitorato e utilizzato per la previsione. (O se correlato a un evento, viene eseguito in modo da rendere la connessione incredibilmente tenue, come "la cifra dei nanosecondi del tempo dell'ultimo clic del mouse")

Numeri deterministici

I matematici possono provare cose su formule e funzioni. Quindi è possibile dimostrare che una funzione, quando viene chiamata ripetutamente, non dà alcun bias o preferenza a nessun modello, oltre al modello semplice "questi sono gli output di quella funzione se chiamati ripetutamente".

Quindi, per esempio, se scegli un numero tra 1 e 10 milioni, scrivilo in binario e "hash" ripetutamente, otterrai una sequenza di cifre dall'aspetto piuttosto casuale. È quasi casuale, ma in realtà non è affatto casuale. Puoi prevedere dato l'algoritmo e qualsiasi stato, quale sarà il prossimo numero.

Lo chiamiamo "pseudocasuale" perché sembra e sembra essere principalmente casuale, anche se non lo è.

Ecco un buon esempio. Pensa a questa sequenza di "numeri casuali" a 3 cifre: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Diciamo che ti dico Posso generare un milione di numeri allo stesso modo. Puoi quindi passare a uno statistico che confermerà (diciamo) che sono distribuiti equamente o qualunque cosa sia. Non esiste un modello prevedibile ovvio. Sembrano piuttosto casuali, giusto? Ma ora ti dico che lo sono davvero

la 500a + cifra di Pi, raggruppata in 3 secondi.

Improvvisamente, per quanto casuale il

cifre di Pi

può essere, puoi immediatamente prevedere che i prossimi 2 numeri saranno 986 e 094.

Per essere chiari, non so esattamente quanto sia casuale

cifre di Pi

siamo. Sarà stato studiato e la risposta ben nota. Ma il punto è questo: in linea di principio, la stessa conclusione è vera per qualsiasi fonte prodotta seguendo un processo deterministico .

Nel mezzo

Tra i due, ci sono tutta una serie di "cose ​​che sembrano casuali e sono spesso casuali in una certa misura". Maggiore è la casualità e quasi la casualità che si possono mescolare, minore è la tendenza all'output di poter rilevare matematicamente qualsiasi modello o qualsiasi output previsto.

Torna a von Neumann e alla tua domanda

Come puoi vedere, gli output deterministici potrebbero apparire casuali, ma potrebbero anche, statisticamente, essere distribuiti casualmente. Potrebbero persino utilizzare dati "segreti" o in rapida evoluzione che non abbiamo realistiche speranze di conoscere. Ma finché è deterministico, i numeri non possono mai essere veramente casuali . Possono solo essere "abbastanza vicini al caso che siamo felici di dimenticare la differenza".

Questo è il significato della citazione che hai dato. Un processo deterministico non può dare numeri casuali. Può solo dare numeri che sembrano essere e si comportano come numeri casuali.

Ora possiamo riformulare la tua domanda in questo modo: "L'output del mio computer (o di qualsiasi altro moderno) può apparire e comportarsi in modo totalmente casuale, significa che la citazione di von Neumann è ormai superata e errata?"

Il problema è ancora questo: anche se l'output del tuo computer potrebbe apparire e comportarsi in modo casuale, potrebbe non essere realmente casuale . Se viene calcolato solo in modo deterministico, ciò significa che non c'è nulla che non sia stato causa-effetto prevedibile per ottenere il numero successivo (questo è ciò che significa "deterministico" in questo senso). Iniziamo con alcuni dati esistenti (noti), applichiamo un processo noto (complesso o disordinato o altro) e otteniamo quello che sembra un nuovo "numero casuale". Ma non è casuale, perché il processo è stato deterministico.

Se dici che il tuo metodo includerà un vero generatore casuale hardware, per risolverlo (come un numero casuale generato dal decadimento radioattivo o dal rumore in un semiconduttore), la tua risposta potrebbe ora essere casuale - ma il tuo metodo per definizione non è più deterministico , proprio perché non è più possibile prevedere gli output (o gli effetti) dati gli input / i dati iniziali (cause) .

Von Neumann vince in entrambi i modi, quasi per definizione!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.