Perché non combiniamo generatori di numeri casuali?

Esistono molte applicazioni in cui viene utilizzato un generatore di numeri pseudo casuali. Quindi le persone ne implementano uno che ritengono ottimo solo per scoprire in seguito che è difettoso. Qualcosa di simile è successo di recente con il generatore di numeri casuali Javascript. RandU anche molto prima. Ci sono anche problemi di seeding iniziale inappropriato per qualcosa come Twister.

Non riesco a trovare esempi di nessuno che combini due o più famiglie di generatori con il solito operatore xor. Se la potenza del computer è sufficiente per eseguire cose come le implementazioni java.SecureRandom o Twister, perché le persone non le combinano? ISAAC xor XORShift xor RandU dovrebbe essere un buon esempio, e dove puoi vedere la debolezza di un singolo generatore essere mitigata dagli altri. Dovrebbe anche aiutare con la distribuzione di numeri in dimensioni più elevate poiché gli algoritmi intrinseci sono totalmente diversi. C'è qualche principio fondamentale che non dovrebbero essere combinati?

Se dovessi costruire un vero generatore di numeri casuali, le persone probabilmente ti consiglierebbero di combinare due o più fonti di entropia. Il mio esempio è diverso?

Escludo l'esempio comune di diversi registri a scorrimento con feedback lineare che lavorano insieme poiché appartengono alla stessa famiglia.

IIRC (e questo è dalla memoria), il bestseller della Rand del 1955 A Million Random Digits ha fatto qualcosa del genere. Prima che i computer fossero economici, le persone sceglievano numeri casuali da questo libro.

Gli autori hanno generato bit casuali con rumore elettronico, ma questo si è rivelato essere biassoso (è difficile fare un flip-flop trascorso esattamente uguali volte sul flip e sul flop). Tuttavia, la combinazione di bit ha reso la distribuzione molto più uniforme.

Certo, puoi combinare PRNG in questo modo, se vuoi, supponendo che siano seminati in modo indipendente. Tuttavia, sarà più lento e probabilmente non risolverà i problemi più urgenti che le persone hanno.

In pratica, se hai un requisito per un PRNG di altissima qualità, usi un PRNG ben testato per la forza crittografica e lo semini con vera entropia. In tal caso, la modalità di errore più probabile non è un problema con l'algoritmo PRNG stesso; la modalità di fallimento più probabile è la mancanza di entropia adeguata (o forse errori di implementazione). Xoring di più PRNG non aiuta con questa modalità di errore. Quindi, se si desidera un PRNG di altissima qualità, probabilmente non ha molto senso eliminarli.

In alternativa, se si desidera un PRNG statistico abbastanza buono ai fini della simulazione, in genere la preoccupazione n. 1 è la velocità (generare numeri pseudocasuali molto velocemente) o la semplicità (non si vuole dedicare molto tempo allo sviluppo nella ricerca o nell'implementazione). Xor-ing rallenta il PRNG e lo rende più complesso, quindi non risponde nemmeno ai bisogni primari in quel contesto.

Fintanto che mostri ragionevole cura e competenza, i PRNG standard sono più che sufficienti, quindi non c'è davvero alcun motivo per cui abbiamo bisogno di qualcosa di più elaborato (non c'è bisogno di xoring). Se non hai nemmeno livelli minimi di assistenza o competenza, probabilmente non sceglierai qualcosa di complesso come lo xoring e il modo migliore per migliorare le cose è concentrarti su più cure e competenze nella selezione del PRNG piuttosto che su xor-ing.

Bottom line : Fondamentalmente, il trucco xor non risolve i problemi che le persone di solito hanno effettivamente quando usano PRNG.

In effetti, qualcosa di veramente rivoluzionario è stato appena annunciato facendo esattamente questo.

Il professor David Zuckerman dell'Università di Texas e lo studente di dottorato Eshan Chattopadhyay hanno scoperto che un numero casuale di "alta qualità" potrebbe essere generato combinando due fonti casuali di "bassa qualità".

Ecco il loro articolo: Estrattori espliciti a due fonti e funzioni resilienti

Supponiamo che sia una sequenza binaria pseudocasuale. Cioè, ogni è una variabile casuale supportata su e le variabili non sono necessariamente indipendenti. Possiamo pensare a questa sequenza generata nel modo seguente: prima campioniamo un tasto uniformemente casuale , quindi usiamo una funzione per generare la sequenza pseudocasuale.$X_1,\ldots,X_n$$X_i$$\{0,1\}$$X_1,\ldots,X_n$$K$$f(K)$

Come misuriamo quanto è buona la sequenza pseudocasuale ? Mentre è possibile misurare quanto sia buona una particolare realizzazione (diciamo usando la complessità di Kolmogorov), qui mi concentrerò su misure che dipendono dall'intera distribuzione della variabile casuale . Un esempio è l'entropia, ma richiederemo solo due proprietà della nostra misura : (una più grande significa una sequenza più casuale)$X_1,\ldots,X_n$$(X_1,\ldots,X_n)$$L$$L(\cdot)$

• Se è una sequenza deterministica (ovvero una sequenza fissa) quindi . L ( X 1 ⊕ y 1 , … , X n ⊕ y n ) = L ( X 1 , … , X n$y_1,\ldots,y_n$$L(X_1 \oplus y_1, \ldots, X_n \oplus y_n) = L(X_1,\ldots,X_n)$

• Se sono due sequenze pseudocasuali indipendenti, è un bit casuale indipendente e , quindi .$\vec{X^0},\vec{X^1}$$T \in \{0,1\}$$\vec{Z} = \vec{X^T}$$L(\vec{Z}) \geq \min(\vec{X^0},\vec{X^1})$

La prima proprietà significa che la misura è invariante quando si lancia l' bit. La seconda proprietà significa che se mescoliamo due distribuzioni , il risultato è almeno buono quanto il peggiore.$i$$\vec{X},\vec{Y}$

Qualsiasi misura di casualità ragionevole soddisferà la prima proprietà. La seconda proprietà è soddisfatta dalle misure più popolari come l'entropia e l'entropia minima .$H$$H_\infty$

Ora possiamo affermare e dimostrare un teorema che mostra che XORing due sequenze pseudocasuali è sempre una buona idea.

Teorema. Sia due sequenze pseudocasuali indipendenti della stessa lunghezza e sia una misura di casualità ammissibile (una che soddisfi le due condizioni sopra). Quindi$\vec{X},\vec{Y}$$L$

Prova. Supponiamo che . Poi è una miscela di distribuzioni , secondo mista alla distribuzione di . Poiché e una miscela è almeno altrettanto buona della peggior distribuzione che viene miscelata, otteniamo . $L(X) \geq L(Y)$$X \oplus Y$$X \oplus y$$Y$$L(X \oplus y) = L(X)$$L(X \oplus Y) \geq L(X)$$~\square$

Ciò che questo teorema significa è che se si XOR due sequenze pseudocasuali generate usando due chiavi indipendenti , il risultato è sempre almeno buono quanto la sequenza migliore essendo XORed, rispetto a qualsiasi misura di casualità ammissibile.

In pratica, per usare due chiavi indipendenti, probabilmente espandiamo una chiave su due chiavi in ​​modo pseudocasuale. Le due chiavi non sono quindi indipendenti. Tuttavia, se usiamo un modo "costoso" per espandere una chiave in due chiavi, ci aspettiamo che le due chiavi risultanti sembrino "indipendenti", e quindi il teorema rimanga "moralmente". Nella crittografia teorica ci sono modi per rendere precisa questa affermazione.

Dovremmo, quindi, XOR due generatori di numeri pseudocasuali? Se non siamo limitati dalla velocità, questa è sicuramente una buona idea. Ma in pratica abbiamo un limite di velocità. Possiamo quindi porre la seguente domanda. Supponiamo che ci vengano dati due PRNG, ciascuno con un parametro che controlla il tempo di funzionamento (e quindi la forza) del generatore. Ad esempio, potrebbe essere la lunghezza di un LFSR o il numero di round. Supponiamo di usare un PRNG con il parametro , l'altro con il parametro e XOR il risultato. Possiamo supporre che , in modo che il tempo di esecuzione totale sia costante. Qual è la scelta migliore di$T$$T$$T_1$$T_2$$T_1 + T_2 = t$$T_1,T_2$? Qui c'è un compromesso a cui è difficile rispondere in generale. È possibile che l'impostazione sia molto peggiore di o .$(t/2,t/2)$$(t,0)$$(0,t)$

Il miglior consiglio qui è attenersi a un PRNG popolare che è considerato forte. Se puoi risparmiare più tempo per generare la tua sequenza, XOR diverse copie, usando chiavi indipendenti (o chiavi generate espandendo una singola chiave usando un costoso PRNG).

Ci proverò, dato che sono sufficientemente disturbato dal consiglio dato in alcune delle altre risposte.

Sia sequenze di bit infinite generate da due RNG (non necessariamente PRNG che sono deterministici una volta che lo stato iniziale è noto), e stiamo considerando la possibilità di usare la sequenza con la speranza di migliorare il comportamento in un certo senso. Esistono molti modi diversi in cui potrebbe essere considerato migliore o peggiore rispetto a ciascuno di e ; ecco una piccola manciata che ritengo significativa, utile e coerente con il normale uso delle parole "meglio" e "peggio":$\vec{X},\vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X}$$\vec{Y}$

• (0) La probabilità di vera casualità della sequenza aumenta o diminuisce
• (1) Probabilità di aumenti o diminuzioni osservabili della non casualità (rispetto ad alcuni osservatori che applicano una determinata quantità di controllo, presumibilmente)
• (2) Gravità / ovvietà degli aumenti o delle diminuzioni osservabili della non casualità.

Per prima cosa pensiamo a (0), che è l'unico dei tre che ha qualche speranza di essere precisato. Si noti che se, in effetti, uno dei due RNG di input è veramente casuale, imparziale e indipendente dall'altro, anche il risultato XOR sarà davvero casuale e imparziale. Con questo in mente, considera il caso in cui credi che siano flussi di bit isolati imparziali veramente casuali, ma non sei completamente sicuro. Se sono le rispettive probabilità che ti sbagli su ciascuno di essi, allora la probabilità che non sia realmente casuale è quindi , in effetti molto meno da$\vec{X},\vec{Y}$$\varepsilon_X,\varepsilon_Y$$\vec{X} \oplus \vec{Y}$$\leq \varepsilon_X \varepsilon_Y \lt min\{\varepsilon_X,\varepsilon_Y\}$$\varepsilon_X,\varepsilon_Y$ sono considerati molto vicini a 0 ("credi che siano veramente casuali"). E in effetti è anche meglio di così, quando prendiamo in considerazione anche la possibilità che sia veramente indipendente anche quando nessuno dei due è veramente casuale: Pertanto possiamo concludere che in senso (0), XOR non può far male e potrebbe potenzialmente aiutare molto.$\vec{X},\vec{Y}$

Tuttavia, (0) non è interessante per i PRNG, poiché nel caso dei PRNG nessuna delle sequenze in questione ha alcuna possibilità di essere veramente casuale.

Pertanto, per questa domanda, che in realtà riguarda i PRNG, dobbiamo parlare di qualcosa come (1) o (2). Dal momento che quelli sono in termini di proprietà e quantità come "osservabile", "grave", "ovvio", "apparente", ora stiamo parlando della complessità di Kolmogorov e non proverò a renderlo preciso. Ma andrò al punto di fare l'affermazione, si spera non controversa, che, con una misura del genere, "01100110 ..." (periodo = 4) sia peggiore di "01010101 ..." (periodo = 2) che è peggiore di " 00000000 ... "(costante).

Ora, si potrebbe supporre che (1) e (2) seguiranno la stessa tendenza di (0), e che quindi la conclusione "XOR non può far male" potrebbe continuare. Tuttavia, si noti la significativa possibilità che né né fossero osservabilmente non casuali, ma che le correlazioni tra loro causassero essere osservabilmente non casuali. Il caso più grave di questo, ovviamente, è quando (o ), nel qual caso è costante, il peggiore di tutti i risultati possibili; in generale, è facile vedere che, indipendentemente da quanto sono buoni e ,$\vec{X}$$\vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X} = \vec{Y}$$\vec{X} = \mathrm{not}(\vec{Y})$$\vec{X} \oplus \vec{Y}$$\vec{X}$$\vec{Y}$$\vec{X}$e devono essere "vicini" a indipendenti affinché il loro xor sia non osservabilmente non casuale. In effetti, essere non-osservabilmente-dipendente può ragionevolmente essere definito come non-osservabilmente-non casuale.$\vec{Y}$$\vec{X} \oplus \vec{Y}$

Tale dipendenza a sorpresa si rivela essere un grosso problema.

Un esempio di cosa non va

La domanda afferma "Sto escludendo l'esempio comune di diversi registri a scorrimento con feedback lineare che lavorano insieme poiché appartengono alla stessa famiglia". Ma per il momento escluderò tale esclusione, al fine di fornire un esempio molto semplice e chiaro della vita reale del tipo di cose che possono andare storte con XORing.

Il mio esempio sarà una vecchia implementazione di rand () che era su una versione di Unix intorno al 1983. IIRC, questa implementazione della funzione rand () aveva le seguenti proprietà:

• il valore di ogni chiamata a rand () era 15 bit pseudo-casuali, ovvero un numero intero nell'intervallo [0, 32767).
• valori di ritorno successivi si alternano pari-dispari-pari-dispari; cioè il bit meno significativo alternato 0-1-0-1 ...
• il bit meno significativo aveva il periodo 4, il successivo dopo aveva il periodo 8, ... quindi il bit di ordine più alto aveva il periodo .$2^{15}$
• pertanto la sequenza dei valori di ritorno a 15 bit di rand () era periodica con il periodo .$2^{15}$

Non sono stato in grado di individuare il codice sorgente originale, ma immagino di mettere insieme un paio di post in https://groups.google.com/forum/#!topic/comp.os.vms/9k4W6KrRV3A che ha fatto esattamente il seguente (codice C), che concorda con la mia memoria delle proprietà sopra:

#define RAND_MAX 32767
static unsigned int next = 1;
int rand(void)
{
    next = next * 1103515245 + 12345;
    return (next & RAND_MAX);
}
void srand(seed)
unsigned int seed;
{
    next = seed;
}

Come si potrebbe immaginare, provare a usare questo rand () in vari modi ha portato a un assortimento di delusioni.

Ad esempio, ad un certo punto ho provato a simulare una sequenza di lanci di monete casuali prendendo ripetutamente:

rand() & 1

cioè il bit meno significativo. Il risultato fu una semplice alternanza testa-coda-testa-coda. All'inizio era difficile da credere (deve essere un bug nel mio programma!), Ma dopo essermi convinto che fosse vero, ho provato invece a usare il bit meno significativo successivo. Non è molto meglio, come notato in precedenza, quel bit è periodico con il periodo 4. Continuando ad esplorare bit successivamente più alti ha rivelato lo schema che ho notato prima: cioè, ogni successivo bit di ordine superiore aveva il doppio del periodo del precedente, quindi in questo rispetto il bit di ordine più elevato è stato il più utile di tutti. Si noti tuttavia che non esiste una soglia in bianco e nero "bit è utile, bit non è utile" qui; tutto ciò che possiamo veramente dire è che le posizioni dei bit numerate avevano vari gradi di utilità / inutilità.$i$$i-1$

Ho anche provato cose come confondere ulteriormente i risultati o XORing insieme valori restituiti da più chiamate a rand (). XORing coppie di valori rand () successivi è stato ovviamente un disastro, ha provocato tutti i numeri dispari! Per i miei scopi (ovvero produrre una sequenza "apparentemente casuale" di lanci di monete), il risultato di parità costante della XOR era persino peggiore del comportamento dispari alternato dell'originale.

Una leggera variazione lo inserisce nel framework originale: vale a dire che sia la sequenza di valori a 15 bit restituiti da rand () con un dato seed e la sequenza da un seed diverso . Ancora una volta, sarà una sequenza di numeri pari o dispari, che è peggiore del comportamento pari / dispari alternato originale.$\vec{X}$$s_X$$\vec{Y}$$s_Y$$\vec{X} \oplus \vec{Y}$

In altre parole, questo è un esempio in cui XOR ha peggiorato le cose nel senso di (1) e (2), con qualsiasi interpretazione ragionevole. È peggio anche in molti altri modi:

• (3) Il bit meno significativo di XOR è ovviamente distorto, cioè ha frequenze disuguali di 0 e 1, a differenza di qualsiasi posizione di bit numerata in uno degli ingressi che sono tutti imparziali.
• (4) In effetti, per ogni posizione di bit, ci sono coppie di semi per le quali tale posizione di bit è distorta nel risultato XOR e per ogni coppia di semi, ci sono (almeno 5) posizioni di bit che sono polarizzate in XOR risultato.
• (5) Il periodo dell'intera sequenza di valori a 15 bit nel risultato XOR è 1 o , rispetto a per gli originali.$2^{14}$$2^{15}$

Nessuno di (3), (4), (5) è ovvio, ma sono tutti facilmente verificabili.

Infine, consideriamo di reintrodurre il divieto di PRNG della stessa famiglia. Il problema qui, penso, è che non è mai veramente chiaro se due PRNG siano "della stessa famiglia", fino a quando / a meno che qualcuno non inizi a usare l'XOR e noti (o nota un attaccante) le cose peggiorano nel senso di (1) e (2), cioè fino a quando i pattern non casuali nell'output attraversano la soglia da non notato a notato / imbarazzante / disastroso, e a quel punto è troppo tardi.

Sono allarmato da altre risposte qui che danno consigli non qualificati "XOR non può far male" sulla base di misure teoriche che mi sembrano fare un cattivo lavoro nel modellare ciò che la maggior parte della gente considera "buona" e "cattiva" riguardo PRNG nella vita reale. Tale consiglio è contraddetto da esempi chiari e sfacciati in cui XOR peggiora le cose, come l'esempio rand () di cui sopra. Mentre è immaginabile che PRNG relativamente "forti" possano mostrare costantemente il comportamento opposto quando XOR rispetto a quello del PRNG giocattolo che era rand (), rendendo così XOR una buona idea per loro, non ho visto prove in quella direzione, teorica o empirico, quindi mi sembra irragionevole supporre che ciò accada.

Personalmente, dopo essere stato morso a sorpresa da XORing rand () s in gioventù e da innumerevoli altre correlazioni a sorpresa assortite nel corso della mia vita, ho poche ragioni per pensare che il risultato sarà diverso se provo di nuovo tattiche simili. Questo è il motivo per cui, personalmente, sarei molto riluttante a XOR insieme a PRNG multipli a meno che non siano state condotte analisi e controlli molto approfonditi per darmi la certezza che potrebbe essere sicuro farlo per i particolari RNG in questione. Come potenziale cura per quando ho scarsa fiducia in uno o più dei singoli PRNG, è improbabile che XORing aumenti la mia fiducia, quindi è improbabile che lo utilizzi per tale scopo. Immagino che la risposta alla tua domanda sia che questo è un sentimento ampiamente diffuso.

DICHIARAZIONE DI NON RESPONSABILITÀ: questa risposta riguarda rigorosamente "Non lo stiamo facendo" e non "ecco una prova matematica del perché possa o non possa funzionare". Non sostengo che XOR presenti (o meno) eventuali vulnerabilità crittografiche. Il mio punto è solo che l'esperienza ci mostra che schemi anche più semplici quasi sempre introducono conseguenze impreviste - ed è per questo che li evitiamo.

La "casualità" è solo una punta dell'iceberg quando si tratta di RNG e PRNG. Vi sono altre qualità importanti, ad esempio l'uniformità.

Immagina un dado comune che è abbastanza buono da solo. Ma ora diciamo che hai bisogno di un intervallo 1-5 invece di 1-6. La prima cosa che viene in mente è semplicemente cancellare la faccia 6 e sostituirla con una extra 1. La "casualità" rimane (i risultati sono ancora veramente casuali), tuttavia l'uniformità soffre molto: ora 1 ha il doppio delle probabilità rispetto agli altri risultati.

La combinazione dei risultati di più RNG è una pendenza altrettanto scivolosa. Per esempio. la semplice aggiunta di 2 lanci di dadi cancella completamente qualsiasi uniformità, poiché "7" è ora 6 volte più probabile di "2" o "12". Concordo sul fatto che XOR sembra migliore dell'aggiunta a prima vista, ma nei PRNG non risulta nulla a prima vista.

Questo è il motivo per cui tendiamo ad attenerci a implementazioni conosciute, perché qualcuno ha speso un sacco di tempo e denaro per ricercarle e tutte le carenze sono ben note, comprese e possono essere aggirate. Quando lanci il tuo, crei potenzialmente vulnerabilità e dovresti fare uno sforzo simile per dimostrarlo. Come mostra l'esempio di aggiunta dei dadi, la combinazione non può essere molto diversa dalla creazione di uno nuovo da zero.

La sicurezza è una catena, forte quanto il suo componente più debole. Una regola empirica per la sicurezza: ogni volta che combini 2 cose, di solito ottieni una somma di difetti, non una somma di punti di forza.