Perché utilizzare la classe C # System.Random invece di System.Security.Cryptography.RandomNumberGenerator?

Perché qualcuno dovrebbe utilizzare il generatore di numeri casuali "standard" di System.Random invece di utilizzare sempre il generatore di numeri casuali crittograficamente protetto da System.Security.Cryptography.RandomNumberGenerator (o le sue sottoclassi perché RandomNumberGenerator è astratto)?

Nate Lawson ci dice nella sua presentazione di Google Tech Talk " Crypto Strikes Back " al minuto 13:11 di non utilizzare i generatori di numeri casuali "standard" di Python, Java e C # e di utilizzare invece la versione crittograficamente sicura.

Conosco la differenza tra le due versioni di generatori di numeri casuali (vedi domanda 101337 ).

Ma quale logica c'è per non utilizzare sempre il generatore di numeri casuali sicuro? Perché usare System.Random? Forse le prestazioni?

Velocità e intento. Se stai generando un numero casuale e non hai bisogno di sicurezza, perché usare una funzione di crittografia lenta? Non hai bisogno di sicurezza, quindi perché far pensare a qualcun altro che il numero possa essere usato per qualcosa di sicuro quando non lo sarà?

Oltre alla velocità e all'interfaccia più utile ( NextDouble()ecc.), È anche possibile creare una sequenza casuale ripetibile utilizzando un valore seed fisso. Ciò è abbastanza utile, tra l'altro durante i test.

Random gen1 = new Random();     // auto seeded by the clock
Random gen2 = new Random(0);    // Next(10) always yields 7,8,7,5,2,....

Prima di tutto la presentazione che hai collegato parla solo di numeri casuali per motivi di sicurezza. Quindi non pretende che Randomsia dannoso per scopi non di sicurezza.

Ma sostengo che lo sia. L'implementazione .net 4 di Randomè difettosa in diversi modi. Consiglio di usarlo solo se non ti interessa la qualità dei tuoi numeri casuali. Consiglio di utilizzare migliori implementazioni di terze parti.

Difetto 1: la semina

Il costruttore predefinito esegue il seed con l'ora corrente. Pertanto, tutte le istanze di Randomcreate con il costruttore predefinito in un breve lasso di tempo (circa 10 ms) restituiscono la stessa sequenza. Questo è documentato e "by-design". Ciò è particolarmente fastidioso se si desidera eseguire il multi-thread del codice, poiché non è possibile creare semplicemente un'istanza di Randomall'inizio dell'esecuzione di ogni thread.

La soluzione alternativa consiste nel prestare la massima attenzione quando si utilizza il costruttore predefinito e eseguire manualmente il seed quando necessario.

Un altro problema qui è che lo spazio seed è piuttosto piccolo (31 bit). Quindi, se generi 50k istanze di Randomcon semi perfettamente casuali, probabilmente otterrai due volte una sequenza di numeri casuali (a causa del paradosso del compleanno ). Quindi anche la semina manuale non è facile da ottenere.

Difetto 2: la distribuzione dei numeri casuali restituiti da Next(int maxValue)è parziale

Ci sono parametri per i quali Next(int maxValue)chiaramente non è uniforme. Ad esempio se calcoli r.Next(1431655765) % 2otterrai 0circa 2/3 dei campioni. (Codice di esempio alla fine della risposta.)

Difetto 3: il NextBytes()metodo è inefficiente.

Il costo per byte di NextBytes()è grande circa quanto il costo per generare un campione intero completo con Next(). Da questo sospetto che creino effettivamente un campione per byte.

Una migliore implementazione utilizzando 3 byte di ogni campione accelererebbe NextBytes()di quasi un fattore 3.

Grazie a questo difetto Random.NextBytes()è solo circa il 25% più veloce rispetto System.Security.Cryptography.RNGCryptoServiceProvider.GetBytesalla mia macchina (Win7, Core i3 2600MHz).

Sono sicuro che se qualcuno ispezionasse il codice sorgente / byte decompilato troverebbe ancora più difetti di quelli che ho trovato con la mia analisi della scatola nera.

Esempi di codice

r.Next(0x55555555) % 2 è fortemente prevenuto:

Random r = new Random();
const int mod = 2;
int[] hist = new int[mod];
for(int i = 0; i < 10000000; i++)
{
    int num = r.Next(0x55555555);
    int num2 = num % 2;
    hist[num2]++;
}
for(int i=0;i<mod;i++)
    Console.WriteLine(hist[i]);

Prestazione:

byte[] bytes=new byte[8*1024];
var cr=new System.Security.Cryptography.RNGCryptoServiceProvider();
Random r=new Random();

// Random.NextBytes
for(int i=0;i<100000;i++)
{
    r.NextBytes(bytes);
}

//One sample per byte
for(int i=0;i<100000;i++)
{   
    for(int j=0;j<bytes.Length;j++)
      bytes[j]=(byte)r.Next();
}

//One sample per 3 bytes
for(int i=0;i<100000;i++)
{
    for(int j=0;j+2<bytes.Length;j+=3)
    {
        int num=r.Next();
        bytes[j+2]=(byte)(num>>16);   
        bytes[j+1]=(byte)(num>>8);
        bytes[j]=(byte)num;
    }
    //Yes I know I'm not handling the last few bytes, but that won't have a noticeable impact on performance
}

//Crypto
for(int i=0;i<100000;i++)
{
    cr.GetBytes(bytes);
}

System.Random è molto più performante poiché non genera numeri casuali crittograficamente sicuri.

Un semplice test sulla mia macchina che riempie un buffer di 4 byte con dati casuali 1.000.000 di volte richiede 49 ms per Random, ma 2845 ms per RNGCryptoServiceProvider. Nota che se aumenti la dimensione del buffer che stai riempiendo, la differenza si restringe poiché l'overhead per RNGCryptoServiceProvider è meno rilevante.

Le ragioni più ovvie sono già state menzionate, quindi eccone una più oscura: i PRNG crittografici in genere devono essere continuamente riseminati con entropia "reale". Pertanto, se si utilizza un CPRNG troppo spesso, si potrebbe esaurire il pool di entropia del sistema, che (a seconda dell'implementazione del CPRNG) lo indebolirà (consentendo così a un attaccante di prevederlo) o si bloccherà durante il tentativo di riempirsi il suo pool di entropia (diventando così un vettore di attacco per un attacco DoS).

In ogni caso, la tua applicazione è ora diventata un vettore di attacco per altre applicazioni totalmente indipendenti che, a differenza della tua, in realtà dipendono in modo vitale dalle proprietà crittografiche del CPRNG.

Questo è un vero problema del mondo reale, BTW, che è stato osservato su server headless (che naturalmente hanno pool di entropia piuttosto piccoli perché mancano di fonti di entropia come input da mouse e tastiera) che eseguono Linux, dove le applicazioni usano erroneamente il /dev/randomkernel CPRNG per tutti i tipi di numeri casuali, mentre il comportamento corretto sarebbe leggere un piccolo valore seed da /dev/urandome usarlo per creare il proprio PRNG.

Se stai programmando un gioco di carte o una lotteria online, assicurati che la sequenza sia quasi impossibile da indovinare. Tuttavia, se mostri agli utenti, ad esempio, una citazione del giorno in cui le prestazioni sono più importanti della sicurezza.

Questo è stato discusso a lungo, ma alla fine, la questione delle prestazioni è una considerazione secondaria quando si seleziona un RNG. Esiste una vasta gamma di RNG là fuori e il Lehmer LCG in scatola di cui è composta la maggior parte degli RNG di sistema non è il migliore né necessariamente il più veloce. Su sistemi vecchi e lenti era un ottimo compromesso. Quel compromesso è raramente davvero rilevante in questi giorni. La cosa persiste nei sistemi odierni principalmente perché A) la cosa è già costruita, e non c'è una vera ragione per `` reinventare la ruota '' in questo caso, e B) per ciò per cui la maggior parte delle persone la userà, è 'abbastanza buono'.

In definitiva, la selezione di un RNG si riduce al rapporto rischio / rendimento. In alcune applicazioni, ad esempio un videogioco, non c'è alcun rischio. Un Lehmer RNG è più che adeguato ed è piccolo, conciso, veloce, ben compreso e "nella scatola".

Se l'applicazione è, ad esempio, un gioco di poker o una lotteria online in cui sono coinvolti premi effettivi e denaro reale entra in gioco a un certo punto dell'equazione, il Lehmer "in the box" non è più adeguato. In una versione a 32 bit, ha solo 2 ^ 32 possibili stati validi prima che inizi a funzionare al meglio . In questi giorni, questa è una porta aperta a un attacco di forza bruta. In un caso come questo, lo sviluppatore vorrà andare a qualcosa come un RNG di periodo molto lungo di alcune specie e probabilmente iniziarlo da un provider crittograficamente forte. Questo offre un buon compromesso tra velocità e sicurezza. In tal caso, la persona andrà alla ricerca di qualcosa come il Mersenne Twister , o un generatore ricorsivo multiplo di qualche tipo.

Se l'applicazione è qualcosa come la comunicazione di grandi quantità di informazioni finanziarie su una rete, ora c'è un rischio enorme e supera di gran lunga qualsiasi possibile ricompensa. Ci sono ancora auto blindate perché a volte gli uomini pesantemente armati sono l'unica sicurezza adeguata, e credimi, se una brigata di agenti speciali con carri armati, combattenti ed elicotteri fosse finanziariamente fattibile, sarebbe il metodo di scelta. In un caso come questo, ha senso utilizzare un RNG crittograficamente potente, perché qualunque sia il livello di sicurezza che puoi ottenere, non è quanto vuoi. Quindi prenderai tutto ciò che puoi trovare e il costo è un problema di secondo posto molto, molto remoto, in termini di tempo o denaro. E se questo significa che ogni sequenza casuale impiega 3 secondi per essere generata su un computer molto potente, dovrai aspettare i 3 secondi,

Si noti che la classe System.Random in C # è codificata in modo errato, quindi dovrebbe essere evitata.

https://connect.microsoft.com/VisualStudio/feedback/details/634761/system-random-serious-bug#tabs

Non tutti hanno bisogno di numeri casuali crittograficamente sicuri e potrebbero trarre maggiori vantaggi da una semplice prng più veloce. Forse la cosa più importante è che puoi controllare la sequenza per i numeri System.Random.

In una simulazione che utilizza numeri casuali che potresti voler ricreare, riesegui la simulazione con lo stesso seme. Può essere utile per tenere traccia dei bug quando si desidera rigenerare anche un determinato scenario difettoso, eseguendo il programma con la stessa identica sequenza di numeri casuali che ha causato il crash del programma.

Se non ho bisogno della sicurezza, cioè, voglio solo un valore relativamente indeterminato non uno che sia crittograficamente forte, Random ha un'interfaccia molto più semplice da usare.

Esigenze diverse richiedono RNG diversi. Per la crittografia, vuoi che i tuoi numeri casuali siano il più casuali possibile. Per le simulazioni Monte Carlo, si desidera che riempiano lo spazio in modo uniforme e che siano in grado di avviare l'RNG da uno stato noto.

Random non è un generatore di numeri casuali, è un generatore di sequenze pseudo-casuali deterministiche, che prende il nome per ragioni storiche.

Il motivo per utilizzarlo System.Randomè se si desidera queste proprietà, vale a dire una sequenza deterministica, che garantisce la produzione della stessa sequenza di risultati quando inizializzata con lo stesso seme.

Se vuoi migliorare la "casualità" senza sacrificare l'interfaccia, puoi ereditare System.Randomsovrascrivendo diversi metodi.

• https://msdn.microsoft.com/en-us/library/system.random.sample(v=vs.110).aspx

Perché vorresti una sequenza deterministica

Un motivo per avere una sequenza deterministica piuttosto che una vera casualità è perché è ripetibile.

Ad esempio, se si esegue una simulazione numerica, è possibile inizializzare la sequenza con un numero casuale (vero) e registrare quale numero è stato utilizzato .

Quindi, se desideri ripetere la stessa identica simulazione, ad esempio per scopi di debug, puoi farlo inizializzando invece la sequenza con il valore registrato .

Perché dovresti volere questa sequenza particolare, non molto buona

L'unico motivo a cui riesco a pensare sarebbe per la retrocompatibilità con il codice esistente che utilizza questa classe.

In breve, se vuoi migliorare la sequenza senza cambiare il resto del tuo codice, vai avanti.

Ho scritto un gioco (Crystal Sliders su iPhone: qui ) che avrebbe messo una serie "casuale" di gemme (immagini) sulla mappa e avresti ruotato la mappa come volevi, selezionandole e se ne andavano. - Simile a Bejeweled. Stavo usando Random (), ed è stato seminato con il numero di tick 100ns dall'avvio del telefono, un seme piuttosto casuale.

Ho trovato incredibile che avrebbe generato giochi quasi identici tra loro: delle 90 gemme circa, di 2 colori, avrei ottenuto due ESATTAMENTE uguali tranne da 1 a 3 gemme! Se lanci 90 monete e ottieni lo stesso schema tranne che per 1-3 lanci, è MOLTO improbabile! Ho diverse schermate che mostrano loro lo stesso. Sono rimasto scioccato da quanto fosse cattivo System.Random ()! Ho pensato che DEVO aver scritto qualcosa di terribilmente sbagliato nel mio codice e che lo stavo usando in modo sbagliato. Mi sbagliavo però, era il generatore.

Come esperimento - e come soluzione finale, sono tornato al generatore di numeri casuali che utilizzo dal 1985 o giù di lì - che è MOLTO meglio. È più veloce, ha un periodo di 1,3 * 10 ^ 154 (2 ^ 521) prima che si ripeta. L'algoritmo originale è stato seminato con un numero a 16 bit, ma l'ho cambiato in un numero a 32 bit e ho migliorato il seeding iniziale.

Quello originale è qui:

ftp://ftp.grnet.gr/pub/lang/algorithms/c/jpl-c/random.c

Nel corso degli anni, ho eseguito tutti i test con numeri casuali a cui riuscivo a pensare, e li ho superati tutti. Non mi aspetto che abbia alcun valore come crittografia, ma restituisce un numero veloce come "return * p ++;" finché non esaurisce i 521 bit, quindi esegue un rapido processo sui bit per crearne di nuovi casuali.

Ho creato un wrapper C # - chiamato JPLRandom () ha implementato la stessa interfaccia di Random () e ha cambiato tutti i punti in cui l'ho chiamato nel codice.

La differenza era ESTREMAMENTE migliore - OMG sono rimasto sbalordito - non dovrebbe esserci alcun modo di poterlo dire guardando gli schermi di circa 90 gemme in uno schema, ma ho fatto una versione di emergenza del mio gioco dopo questo.

E non userei mai più System.Random () per niente. Sono SCOLORATO che la loro versione sia stata spazzata via da qualcosa che ora ha 30 anni!

-Traderhut Games