Java.util.Random è davvero così casuale? Come posso generare 52! (fattoriali) possibili sequenze?

Ho usato Random (java.util.Random)per mescolare un mazzo di 52 carte. Ce ne sono 52! (8.0658175e + 67) possibilità. Tuttavia, ho scoperto che il seme per java.util.Randomè a long, che è molto più piccolo a 2 ^ 64 (1.8446744e + 19).

Da qui, ho il sospetto che java.util.Random sia davvero così casuale ; è effettivamente in grado di generare tutti i 52! possibilità?

In caso contrario, come posso generare in modo affidabile una sequenza casuale migliore in grado di produrre tutti i 52! possibilità?

La selezione di una permutazione casuale richiede simultaneamente una casualità sempre maggiore rispetto a quanto implica la tua domanda. Lasciatemi spiegare.

Le cattive notizie: servono più casualità.

Il difetto fondamentale nel tuo approccio è che sta cercando di scegliere tra ~ 2 ²²⁶ possibilità usando 64 bit di entropia (il seme casuale). Per scegliere equamente tra ~ 2 ²²⁶ possibilità dovrai trovare un modo per generare 226 bit di entropia anziché 64.

Esistono diversi modi per generare bit casuali: hardware dedicato , istruzioni CPU , interfacce del sistema operativo , servizi online . C'è già un presupposto implicito nella tua domanda che puoi in qualche modo generare 64 bit, quindi fai tutto ciò che avresti fatto, solo quattro volte e donare i pezzi in eccesso in beneficenza. :)

La buona notizia: serve meno casualità.

Una volta che hai quei 226 bit casuali, il resto può essere fatto in modo deterministico e quindi le proprietà di java.util.Randompossono essere rese irrilevanti . Ecco come.

Diciamo che generiamo tutti e 52! permutazioni (orso con me) e ordinarle lessicograficamente.

Per scegliere una delle permutazioni ci serve solo un intero intero casuale tra 0e 52!-1. Quel numero intero è il nostro 226 bit di entropia. Lo useremo come indice nel nostro elenco ordinato di permutazioni. Se l'indice casuale è distribuito uniformemente, non solo ti viene garantito che tutte le permutazioni possono essere scelte, ma verranno scelte in modo equiprobabile (che è una garanzia più forte di quello che la domanda si pone).

Ora, in realtà non è necessario generare tutte quelle permutazioni. Puoi produrne uno direttamente, data la sua posizione scelta casualmente nel nostro ipotetico elenco ordinato. Questo può essere fatto in O (n ² ) tempo usando il codice Lehmer ^[1] (vedi anche permutazioni di numerazione e sistema numerico factoriadico ). La n qui è la dimensione del tuo mazzo, cioè 52.

C'è un'implementazione C in questa risposta StackOverflow . Ci sono diverse variabili intere lì che traboccerebbero per n = 52, ma fortunatamente in Java puoi usare java.math.BigInteger. Il resto dei calcoli può essere trascritto quasi com'è:

public static int[] shuffle(int n, BigInteger random_index) {
    int[] perm = new int[n];
    BigInteger[] fact = new BigInteger[n];
    fact[0] = BigInteger.ONE;
    for (int k = 1; k < n; ++k) {
        fact[k] = fact[k - 1].multiply(BigInteger.valueOf(k));
    }

    // compute factorial code
    for (int k = 0; k < n; ++k) {
        BigInteger[] divmod = random_index.divideAndRemainder(fact[n - 1 - k]);
        perm[k] = divmod[0].intValue();
        random_index = divmod[1];
    }

    // readjust values to obtain the permutation
    // start from the end and check if preceding values are lower
    for (int k = n - 1; k > 0; --k) {
        for (int j = k - 1; j >= 0; --j) {
            if (perm[j] <= perm[k]) {
                perm[k]++;
            }
        }
    }

    return perm;
}

public static void main (String[] args) {
    System.out.printf("%s\n", Arrays.toString(
        shuffle(52, new BigInteger(
            "7890123456789012345678901234567890123456789012345678901234567890"))));
}

^[1] Da non confondere con Lehrer . :)

La tua analisi è corretta: il seeding di un generatore di numeri pseudo-casuale con qualsiasi seme specifico deve produrre la stessa sequenza dopo uno shuffle, limitando il numero di permutazioni che potresti ottenere a 2 ⁶⁴ . Questa affermazione è facile da verificare sperimentalmente chiamando Collection.shuffledue volte, passando un Randomoggetto inizializzato con lo stesso seme e osservando che i due shuffle casuali sono identici.

Una soluzione a questo, quindi, è usare un generatore di numeri casuali che consenta un seme più grande. Java fornisce una SecureRandomclasse che potrebbe essere inizializzata con byte[]array di dimensioni praticamente illimitate. È quindi possibile passare un'istanza di SecureRandomto Collections.shuffleper completare l'attività:

byte seed[] = new byte[...];
Random rnd = new SecureRandom(seed);
Collections.shuffle(deck, rnd);

In generale, un generatore di numeri pseudocasuali (PRNG) non può scegliere tra tutte le permutazioni di un elenco di 52 elementi se la sua lunghezza di stato è inferiore a 226 bit.

java.util.Randomimplementa un algoritmo con un modulo di 2 ⁴⁸ ; quindi la sua lunghezza dello stato è di soli 48 bit, molto meno dei 226 bit a cui mi riferivo. Dovrai utilizzare un altro PRNG con una lunghezza dello stato maggiore, in particolare uno con un periodo di 52 fattoriale o superiore.

Vedi anche "Mischiare" nel mio articolo sui generatori di numeri casuali .

Questa considerazione è indipendente dalla natura del PRNG; si applica ugualmente ai PRNG crittografici e non crittografici (ovviamente, i PRNG non crittografici sono inappropriati ogni volta che si tratta di sicurezza delle informazioni).

Sebbene java.security.SecureRandomconsenta il passaggio di seed di lunghezza illimitata, l' SecureRandomimplementazione potrebbe utilizzare un PRNG sottostante (ad esempio, "SHA1PRNG" o "DRBG"). E dipende dal periodo di quel PRNG (e, in misura minore, dalla lunghezza dello stato) se è in grado di scegliere tra 52 permutazioni fattoriali. (Nota che definisco "lunghezza dello stato" come "la dimensione massima del seme che un PRNG può prendere per inizializzare il suo stato senza accorciare o comprimere quel seme ").

Vorrei scusarmi in anticipo, perché è un po 'difficile da capire ...

Prima di tutto, sai già che java.util.Randomnon è del tutto casuale. Genera sequenze in modo perfettamente prevedibile dal seme. Hai perfettamente ragione, dal momento che il seme è lungo solo 64 bit, può generare solo 2 ^ 64 sequenze diverse. Se dovessi in qualche modo generare 64 bit casuali reali e usarli per selezionare un seme, non potresti usare quel seme per scegliere casualmente tra tutti i 52! possibili sequenze con uguale probabilità.

Tuttavia, questo fatto non ha alcuna conseguenza finché non si generano più di 2 ^ 64 sequenze, purché non vi sia nulla di "speciale" o "notevolmente speciale" sulle sequenze 2 ^ 64 che può generare .

Diciamo che hai avuto un PRNG molto migliore che utilizzava semi a 1000 bit. Immagina di avere due modi per inizializzarlo: un modo lo inizializzerebbe usando l'intero seme e un modo lo avrebbe ridotto a 64 bit prima di inizializzarlo.

Se non sapessi quale inizializzatore fosse quale, potresti scrivere qualsiasi tipo di test per distinguerli? A meno che tu non sia stato (non) abbastanza fortunato da finire per inizializzare il cattivo con gli stessi 64 bit due volte, allora la risposta è no. Non è possibile distinguere tra i due inizializzatori senza una conoscenza dettagliata di alcuni punti deboli nell'implementazione specifica del PRNG.

In alternativa, immagina che la Randomclasse avesse un array di 2 ^ 64 sequenze che sono state selezionate completamente e casualmente in qualche momento in un lontano passato e che il seme era solo un indice in questo array.

Quindi il fatto che Randomusi solo 64 bit per il suo seme è in realtà non è necessariamente un problema statistico, fintanto che non v'è alcuna possibilità significativa che verrà utilizzato lo stesso seme per due volte.

Naturalmente, per scopi crittografici , un seme a 64 bit non è abbastanza, perché ottenere un sistema per usare lo stesso seme due volte è fattibile dal punto di vista computazionale.

MODIFICARE:

Dovrei aggiungere che, anche se tutto quanto sopra è corretto, che l'implementazione effettiva di java.util.Randomnon è eccezionale. Se stai scrivendo un gioco di carte, potresti usare l' MessageDigestAPI per generare l'hash SHA-256 "MyGameName"+System.currentTimeMillis()e usare quei bit per mescolare il mazzo. Con l'argomento sopra, fintanto che i tuoi utenti non stanno davvero giocando d'azzardo, non devi preoccuparti che currentTimeMillisritorni a lungo. Se i tuoi utenti stanno davvero giocando d'azzardo, usa SecureRandomsenza seed.

Ho intenzione di prendere un po 'di virata diversa su questo. Hai ragione sui tuoi presupposti: il tuo PRNG non sarà in grado di colpire tutti e 52! possibilità.

La domanda è: qual è la scala del tuo gioco di carte?

Se stai realizzando un semplice gioco in stile Klondike? Quindi sicuramente non hai bisogno di tutti i 52! possibilità. Invece, guarda in questo modo: un giocatore avrà 18 quintilioni di giochi distinti. Anche tenendo conto del "problema del compleanno", dovrebbero giocare miliardi di mani prima di imbattersi nel primo gioco duplicato.

Se stai realizzando una simulazione monte-carlo? Allora probabilmente stai bene. Potrebbe essere necessario gestire gli artefatti a causa della 'P' nel PRNG, ma probabilmente non si verificheranno problemi semplicemente a causa di uno spazio di semi ridotto (di nuovo, si stanno esaminando quintilioni di possibilità uniche). rovescio della medaglia, se stai lavorando con un conteggio di iterazioni di grandi dimensioni, quindi, sì, il tuo spazio seme basso potrebbe essere un affare.

Se stai realizzando un gioco di carte multiplayer, in particolare se ci sono soldi sulla linea? Quindi dovrai cercare su come i siti di poker online gestiscono lo stesso problema di cui ti stai chiedendo. Perché mentre il problema di spazio di seeding basso non è evidente per il giocatore medio, è sfruttabile se vale la pena investire tempo. (Tutti i siti di poker hanno attraversato una fase in cui i loro PRNG sono stati "hackerati", permettendo a qualcuno di vedere le carte coperte di tutti gli altri giocatori, semplicemente deducendo il seme dalle carte scoperte.) Se questa è la situazione in cui ti trovi, don 't semplicemente trovare un migliore PRNG - è necessario trattarlo come serio come un problema Crypto.

Soluzione breve che è essenzialmente la stessa di dasblinkenlight:

// Java 7
SecureRandom random = new SecureRandom();
// Java 8
SecureRandom random = SecureRandom.getInstanceStrong();

Collections.shuffle(deck, random);

Non devi preoccuparti dello stato interno. Spiegazione lunga del perché:

Quando si crea un SecureRandom un'istanza in questo modo, accede a un generatore di numeri casuali veri specifici del sistema operativo. Questo è un pool di entropia in cui si accede a valori che contengono bit casuali (ad esempio per un timer a nanosecondi la precisione dei nanosecondi è essenzialmente casuale) o un generatore di numeri hardware interno.

Questo input (!) Che può ancora contenere tracce spurie viene immesso in un hash crittograficamente forte che rimuove tali tracce. Questo è il motivo per cui vengono utilizzati quei CSPRNG, non per creare quei numeri stessi! Il SecureRandomha un contatore che traccia quanti bit sono stati utilizzati ( getBytes(), getLong()etc.) e ricariche la SecureRandomcon bit entropia quando necessario .

In breve: dimentica semplicemente le obiezioni e usalo SecureRandomcome vero generatore di numeri casuali.

Se consideri il numero solo come un array di bit (o byte), forse potresti utilizzare le Random.nextBytessoluzioni (sicure) suggerite in questa domanda Stack Overflow e quindi mappare l'array in a new BigInteger(byte[]).

Un algoritmo molto semplice è applicare SHA-256 a una sequenza di numeri interi che va da 0 in su. (Se si desidera "ottenere una sequenza diversa", è possibile aggiungere un salt.) Se assumiamo che l'output di SHA-256 sia "buono come" interi distribuiti uniformemente tra 0 e 2 ²⁵⁶ - 1, allora abbiamo abbastanza entropia per il compito.

Per ottenere una permutazione dall'output di SHA256 (quando espresso come numero intero) è sufficiente ridurlo modulo 52, 51, 50 ... come in questo pseudocodice:

deck = [0..52]
shuffled = []
r = SHA256(i)

while deck.size > 0:
    pick = r % deck.size
    r = floor(r / deck.size)

    shuffled.append(deck[pick])
    delete deck[pick]