Come seminare in modo succinto, portatile e completo il PRNG mt19937?

Mi sembra di vedere molte risposte in cui qualcuno suggerisce di utilizzare <random>per generare numeri casuali, di solito insieme a codice come questo:

std::random_device rd;  
std::mt19937 gen(rd());
std::uniform_int_distribution<> dis(0, 5);
dis(gen);

Di solito questo sostituisce una sorta di "abominio empio" come:

srand(time(NULL));
rand()%6;

Potremmo criticare il vecchio modo sostenendo che time(NULL)fornisce bassa entropia, time(NULL)è prevedibile e il risultato finale non è uniforme.

Ma tutto questo è vero per il nuovo modo: ha solo un rivestimento più brillante.

• rd()restituisce un singolo unsigned int. Questo ha almeno 16 bit e probabilmente 32. Non è sufficiente per seminare i 19937 bit di stato di MT.

• L'utilizzo std::mt19937 gen(rd());gen()(seeding con 32 bit e guardando il primo output) non fornisce una buona distribuzione dell'output. 7 e 13 non possono mai essere la prima uscita. Due semi producono 0. Dodici semi producono 1226181350. ( Link )

• std::random_devicepuò essere, e talvolta lo è, implementato come un semplice PRNG con un seed fisso. Potrebbe quindi produrre la stessa sequenza in ogni esecuzione. ( Link ) Questo è anche peggio di time(NULL).

Peggio ancora, è molto facile copiare e incollare gli snippet di codice precedenti, nonostante i problemi che contengono. Alcune soluzioni a questo richiedono l'acquisizione di biblioteche di grandi dimensioni che potrebbero non essere adatte a tutti.

Alla luce di ciò, la mia domanda è: come si può seminare in modo succinto, portabile e completo il PRNG mt19937 in C ++?

Dati i problemi di cui sopra, una buona risposta:

• Deve seminare completamente il mt19937 / mt19937_64.
• Non posso fare affidamento esclusivamente su std::random_deviceo time(NULL)come fonte di entropia.
• Non dovrebbe fare affidamento su Boost o altre biblioteche.
• Dovrebbe rientrare in un piccolo numero di righe in modo tale da sembrare piacevole da copiare e incollare in una risposta.

Pensieri

• Il mio pensiero attuale è che gli output di std::random_devicepossono essere combinati (forse tramite XOR) con time(NULL)valori derivati ​​dalla randomizzazione dello spazio degli indirizzi e una costante hard-coded (che potrebbe essere impostata durante la distribuzione) per ottenere il massimo sforzo con l'entropia.

• std::random_device::entropy() non fornisce una buona indicazione di ciò che std::random_devicepotrebbe o non potrebbe fare.

Direi che il più grande difetto std::random_deviceè che è consentito un fallback deterministico se non è disponibile CSPRNG. Questo da solo è un buon motivo per non seminare un PRNG utilizzando std::random_device, poiché i byte prodotti possono essere deterministici. Sfortunatamente non fornisce un'API per scoprire quando ciò accade o per richiedere un errore invece di numeri casuali di bassa qualità.

Cioè, non esiste una soluzione completamente portabile : tuttavia, esiste un approccio decente e minimo. È possibile utilizzare un wrapper minimo attorno a un CSPRNG (definito come di sysrandomseguito) per eseguire il seeding del PRNG.

finestre

Puoi fare affidamento su CryptGenRandomun CSPRNG. Ad esempio, puoi utilizzare il codice seguente:

bool acquire_context(HCRYPTPROV *ctx)
{
    if (!CryptAcquireContext(ctx, nullptr, nullptr, PROV_RSA_FULL, 0)) {
        return CryptAcquireContext(ctx, nullptr, nullptr, PROV_RSA_FULL, CRYPT_NEWKEYSET);
    }
    return true;
}


size_t sysrandom(void* dst, size_t dstlen)
{
    HCRYPTPROV ctx;
    if (!acquire_context(&ctx)) {
        throw std::runtime_error("Unable to initialize Win32 crypt library.");
    }

    BYTE* buffer = reinterpret_cast<BYTE*>(dst);
    if(!CryptGenRandom(ctx, dstlen, buffer)) {
        throw std::runtime_error("Unable to generate random bytes.");
    }

    if (!CryptReleaseContext(ctx, 0)) {
        throw std::runtime_error("Unable to release Win32 crypt library.");
    }

    return dstlen;
}

Unix-Like

Su molti sistemi Unix-like, dovresti usare / dev / urandom quando possibile (sebbene non sia garantito che esista su sistemi conformi a POSIX).

size_t sysrandom(void* dst, size_t dstlen)
{
    char* buffer = reinterpret_cast<char*>(dst);
    std::ifstream stream("/dev/urandom", std::ios_base::binary | std::ios_base::in);
    stream.read(buffer, dstlen);

    return dstlen;
}

Altro

Se nessun CSPRNG è disponibile, potresti scegliere di fare affidamento su std::random_device. Tuttavia, lo eviterei se possibile, poiché vari compilatori (in particolare, MinGW) lo implementano come PRNG (in effetti, producendo la stessa sequenza ogni volta per avvisare gli umani che non è propriamente casuale).

Semina

Ora che abbiamo i nostri pezzi con un sovraccarico minimo, possiamo generare i bit desiderati di entropia casuale per seminare il nostro PRNG. L'esempio utilizza 32 bit (ovviamente insufficienti) per inizializzare il PRNG e dovresti aumentare questo valore (che dipende dal tuo CSPRNG).

std::uint_least32_t seed;    
sysrandom(&seed, sizeof(seed));
std::mt19937 gen(seed);

Confronto con Boost

Possiamo vedere parallelismi con boost :: random_device (un vero CSPRNG) dopo una rapida occhiata al codice sorgente . Boost utilizza MS_DEF_PROVsu Windows, che è il tipo di provider per PROV_RSA_FULL. L'unica cosa che manca sarebbe la verifica del contesto crittografico, che può essere fatto con CRYPT_VERIFYCONTEXT. Su * Nix, Boost utilizza /dev/urandom. IE, questa soluzione è portatile, ben testata e facile da usare.

Specializzazione Linux

Se sei disposto a sacrificare la concisione per la sicurezza, getrandomè una scelta eccellente su Linux 3.17 e versioni successive e su Solaris recente. getrandomsi comporta in modo identico a /dev/urandom, tranne che si blocca se il kernel non ha ancora inizializzato il suo CSPRNG dopo l'avvio. Il frammento di codice seguente rileva se Linux getrandomè disponibile e, in caso contrario, ricade su /dev/urandom.

#if defined(__linux__) || defined(linux) || defined(__linux)
#   // Check the kernel version. `getrandom` is only Linux 3.17 and above.
#   include <linux/version.h>
#   if LINUX_VERSION_CODE >= KERNEL_VERSION(3,17,0)
#       define HAVE_GETRANDOM
#   endif
#endif

// also requires glibc 2.25 for the libc wrapper
#if defined(HAVE_GETRANDOM)
#   include <sys/syscall.h>
#   include <linux/random.h>

size_t sysrandom(void* dst, size_t dstlen)
{
    int bytes = syscall(SYS_getrandom, dst, dstlen, 0);
    if (bytes != dstlen) {
        throw std::runtime_error("Unable to read N bytes from CSPRNG.");
    }

    return dstlen;
}

#elif defined(_WIN32)

// Windows sysrandom here.

#else

// POSIX sysrandom here.

#endif

OpenBSD

C'è un ultimo avvertimento: il moderno OpenBSD non ha /dev/urandom. Dovresti invece usare getentropy .

#if defined(__OpenBSD__)
#   define HAVE_GETENTROPY
#endif

#if defined(HAVE_GETENTROPY)
#   include <unistd.h>

size_t sysrandom(void* dst, size_t dstlen)
{
    int bytes = getentropy(dst, dstlen);
    if (bytes != dstlen) {
        throw std::runtime_error("Unable to read N bytes from CSPRNG.");
    }

    return dstlen;
}

#endif

Altri pensieri

Se hai bisogno di byte casuali crittograficamente sicuri, dovresti probabilmente sostituire fstream con l'apertura / lettura / chiusura senza buffer di POSIX. Questo perché entrambi basic_filebufe FILEcontengono un buffer interno, che verrà allocato tramite un allocatore standard (e quindi non cancellato dalla memoria).

Questo potrebbe essere fatto facilmente cambiando sysrandomin:

size_t sysrandom(void* dst, size_t dstlen)
{
    int fd = open("/dev/urandom", O_RDONLY);
    if (fd == -1) {
        throw std::runtime_error("Unable to open /dev/urandom.");
    }
    if (read(fd, dst, dstlen) != dstlen) {
        close(fd);
        throw std::runtime_error("Unable to read N bytes from CSPRNG.");
    }

    close(fd);
    return dstlen;
}

Grazie

Un ringraziamento speciale a Ben Voigt per aver sottolineato che FILEutilizza letture bufferizzate, e quindi non dovrebbe essere utilizzato.

Vorrei anche ringraziare Peter Cordes per aver menzionato getrandome la mancanza di OpenBSD /dev/urandom.

In un certo senso, questo non può essere fatto in modo portabile. Cioè, si può concepire una valida piattaforma completamente deterministica che esegue C ++ (diciamo, un simulatore che fa avanzare il clock della macchina in modo deterministico e con I / O "determinizzato") in cui non vi è alcuna fonte di casualità per seminare un PRNG.

Puoi usare un std::seed_seqe riempirlo almeno fino alla dimensione dello stato richiesto per il generatore usando il metodo di Alexander Huszagh per ottenere l'entropia:

size_t sysrandom(void* dst, size_t dstlen); //from Alexander Huszagh answer above

void foo(){

    std::array<std::mt19937::UIntType, std::mt19937::state_size> state;
    sysrandom(state.begin(), state.length*sizeof(std::mt19937::UIntType));
    std::seed_seq s(state.begin(), state.end());

    std::mt19937 g;
    g.seed(s);
}

Se ci fosse un modo corretto per riempire o creare una SeedSequence da un UniformRandomBitGenerator nella libreria standard, usare std::random_deviceper il seeding correttamente sarebbe molto più semplice.

L'implementazione su cui sto lavorando sfrutta la state_sizeproprietà del mt19937PRNG per decidere quanti seed fornire in fase di inizializzazione:

using Generator = std::mt19937;

inline
auto const& random_data()
{
    thread_local static std::array<typename Generator::result_type, Generator::state_size> data;
    thread_local static std::random_device rd;

    std::generate(std::begin(data), std::end(data), std::ref(rd));

    return data;
}

inline
Generator& random_generator()
{
    auto const& data = random_data();

    thread_local static std::seed_seq seeds(std::begin(data), std::end(data));
    thread_local static Generator gen{seeds};

    return gen;
}

template<typename Number>
Number random_number(Number from, Number to)
{
    using Distribution = typename std::conditional
    <
        std::is_integral<Number>::value,
        std::uniform_int_distribution<Number>,
        std::uniform_real_distribution<Number>
    >::type;

    thread_local static Distribution dist;

    return dist(random_generator(), typename Distribution::param_type{from, to});
}

Penso che ci siano margini di miglioramento perché std::random_device::result_typepotrebbero differire dalle std::mt19937::result_typedimensioni e dalla gamma, quindi dovrebbero essere davvero presi in considerazione.

Una nota su std :: random_device .

Secondo lo C++11(/14/17)standard (s):

26.5.6 Classe random_device [ rand.device ]

2 Se le limitazioni di implementazione impediscono di generare numeri casuali non deterministici, l'implementazione può utilizzare un motore di numeri casuali.

Ciò significa che l'implementazione può generare valori deterministici solo se le è impedito di generare valori non deterministici da qualche limitazione.

Il MinGWcompilatore Windowsnotoriamente non fornisce valori non deterministici dai suoi std::random_device, nonostante siano facilmente disponibili dal sistema operativo. Quindi lo considero un bug e probabilmente non un evento comune tra implementazioni e piattaforme.

Non c'è niente di sbagliato nel seeding usando il tempo, supponendo che non ne hai bisogno per essere sicuro (e non hai detto che era necessario). L'intuizione è che puoi usare l'hashing per correggere la non casualità. Ho trovato che funziona adeguatamente in tutti i casi, inclusi e in particolare per le simulazioni Monte Carlo pesanti.

Una caratteristica interessante di questo approccio è che generalizza all'inizializzazione da altri insiemi di seed non casuali. Ad esempio, se desideri che ogni thread abbia il proprio RNG (per threadsafety), puoi semplicemente inizializzare in base all'ID thread con hash.

Quello che segue è un SSCCE , distillato dalla mia base di codice (per semplicità; alcune strutture di supporto OO elide):

#include <cstdint> //`uint32_t`
#include <functional> //`std::hash`
#include <random> //`std::mt19937`
#include <iostream> //`std::cout`

static std::mt19937 rng;

static void seed(uint32_t seed) {
    rng.seed(static_cast<std::mt19937::result_type>(seed));
}
static void seed() {
    uint32_t t = static_cast<uint32_t>( time(nullptr) );
    std::hash<uint32_t> hasher; size_t hashed=hasher(t);
    seed( static_cast<uint32_t>(hashed) );
}

int main(int /*argc*/, char* /*argv*/[]) {
    seed();
    std::uniform_int_distribution<> dis(0, 5);
    std::cout << dis(rng);
}

Ecco la mia pugnalata alla domanda:

#include <random>
#include <chrono>
#include <cstdint>
#include <algorithm>
#include <functional>
#include <iostream>

uint32_t LilEntropy(){
  //Gather many potential forms of entropy and XOR them
  const  uint32_t my_seed = 1273498732; //Change during distribution
  static uint32_t i = 0;        
  static std::random_device rd; 
  const auto hrclock = std::chrono::high_resolution_clock::now().time_since_epoch().count();
  const auto sclock  = std::chrono::system_clock::now().time_since_epoch().count();
  auto *heap         = malloc(1);
  const auto mash = my_seed + rd() + hrclock + sclock + (i++) +
    reinterpret_cast<intptr_t>(heap)    + reinterpret_cast<intptr_t>(&hrclock) +
    reinterpret_cast<intptr_t>(&i)      + reinterpret_cast<intptr_t>(&malloc)  +
    reinterpret_cast<intptr_t>(&LilEntropy);
  free(heap);
  return mash;
}

//Fully seed the mt19937 engine using as much entropy as we can get our
//hands on
void SeedGenerator(std::mt19937 &mt){
  std::uint_least32_t seed_data[std::mt19937::state_size];
  std::generate_n(seed_data, std::mt19937::state_size, std::ref(LilEntropy));
  std::seed_seq q(std::begin(seed_data), std::end(seed_data));
  mt.seed(q);
}

int main(){
  std::mt19937 mt;
  SeedGenerator(mt);

  for(int i=0;i<100;i++)
    std::cout<<mt()<<std::endl;
}

L'idea qui è di utilizzare XOR per combinare molte potenziali fonti di entropia (tempo veloce, tempo lento, std::random-deviceposizioni di variabili statiche, posizioni di heap, posizioni di funzioni, posizioni di libreria, valori specifici del programma) per fare un tentativo migliore per inizializzare il mt19937. Finché almeno una volta la fonte è "buona", il risultato sarà almeno "buono".

Questa risposta non è breve come sarebbe preferibile e può contenere uno o più errori di logica. Quindi lo considero un work in progress. Si prega di commentare se si dispone di feedback.

• Usa getentropy () per seminare un generatore di numeri pseudocasuali (PRNG).
• Usa getrandom () se vuoi valori casuali (invece di, diciamo, /dev/urandomo /dev/random).

Questi sono disponibili sui moderni sistemi simili a UNIX, come Linux, Solaris e OpenBSD.

Una data piattaforma potrebbe avere una fonte di entropia, come /dev/random. Nanosecondi dall'Epoch con std::chrono::high_resolution_clock::now()è probabilmente il miglior seme nella Standard Library.

In precedenza ho usato qualcosa come (uint64_t)( time(NULL)*CLOCKS_PER_SEC + clock() )ottenere più bit di entropia per applicazioni che non sono critiche per la sicurezza.