Quanto è sicuro seminare i PRNG con le sequenze da CSPRNG?

Prima di tutto non c'è niente di sbagliato nel seminare un CSPRNG con l'output di un altro CSPRNG, fino a quando l'origine è stata seminata correttamente in primo luogo.

Come altri hanno affermato, Mersenne Twister non è un algoritmo crittografico, quindi non dovresti usarlo per un casinò.

/dev/random e /dev/urandom sono costruiti usando un solido CSPRNG su praticamente tutti gli UNIX moderni, salvo per eventuali incidenti con seed improprio che puoi usare per qualsiasi cosa, e in molti sistemi nessuno bloccherà mai una volta che sono stati correttamente seminato.

L'eccezione è Linux in cui viene utilizzata una vecchia funzione di slurry sviluppata in loco al posto della crittografia moderna. /dev/random blocchi in quanto teoricamente in determinate ipotesi rende l'output crittograficamente sicuro, anche se la funzione di slurry non è di forza crittografica. E /dev/urandom lo butta via perché in questo modo si può effettivamente fare un po 'di lavoro.

Linux random non è stato veramente rotto, è solo nella zona di alcuni exploit parziali che sono possibili in condizioni controllate: link

In combinazione con le difficoltà di ottenere solo output incompleti e permuti, non penso sia probabile che un utente malintenzionato possa sfruttare Linux /dev/urandom attraverso il tuo sito. Ma perché rischiare? Puoi tranquillamente usare /dev/random per generare un seme per un CSPRNG corretto. Fintanto che non esporti l'output da /dev/random non importa se la funzione di slurry è crittograficamente strong o meno, un pezzo isolato dell'output è ancora sufficientemente imprevedibile.

Questo sicuramente sembra un'ottimizzazione prematura.

Un CSPRNG veloce su una moderna CPU Intel emetterà tra 500 MB e 2 GB al secondo. Anche se hai un gioco abbastanza casuale che richiede 100 byte casuali al secondo per giocatore (non riesco a pensare ad un tipico gioco da casinò da nessuna parte) un singolo core sarà in grado di generare numeri casuali per dieci milioni di utenti simultanei.

Altre operazioni, come l'accesso al database, il server web, ecc., saranno molto più costose rispetto alla generazione di buoni numeri casuali. Raccomando di seminare un buon codice di flusso come ChaCha o AES-CTR dal generatore casuale di sistema invece di eseguire il downgrade su un PRNG non sicuro. È possibile che il generatore casuale di sistema sia già abbastanza veloce.

Controlla eBACS per i benchmark delle cifre del flusso.

L'utilizzo di PRNG non crittografici come Mersenne-Twister per un casinò online è una pessima idea. Questi generatori non mirano a un'imprevedibilità. Cercano solo di apparire casuali in modo tale che i loro difetti non causino alcuna deviazione dai dati casuali effettivi che rompono il codice usando per sbaglio.

Ad esempio, se hai eseguito una simulazione scientifica con MT e con numeri casuali perfetti e ha dato risultati diversi, questo sarebbe considerato un difetto in MT. Ma non prova a resistere a qualcuno che cerca deliberatamente di prevedere l'output.

Come @CL. già detto, MT è facilmente prevedibile una volta che hai visto alcune centinaia di uscite. Confrontalo con un CSPRNG che sarà indistinguibile per numeri casuali veri anche dopo aver osservato petabyte di dati.

Wikipedia dice :

The algorithm in its native form is not suitable for cryptography (ie it's not a CSPRNG). Observing a sufficient number of iterations (624 in the case of MT19937, since this is the size of the state vector from which future iterations are produced) allows one to predict all future iterations.

In altre parole, anche con un seed strong, ottieni solo alcuni valori di output imprevedibili. La differenza tra Mersenne Twister e CSPRNG è che quest'ultimo rimane imprevedibile per molto più tempo.

Devi riesaminare regolarmente il PRNG. In alternativa, usa un CSPRNG in primo luogo e concentrati sull'ottimizzazione di quello per la velocità.