Il seguente codice semina il PRN di OpenSSL necessario, superfluo o dannoso?

Question

Il seguente codice semina il PRN di OpenSSL necessario, superfluo o dannoso?

#1 da (2 voti)

2

Mentre stavo passando attraverso Crypt :: SSLeay , preparandolo per la prossima versione, ho notato il seguente codice, scritto prima del mio tempo,

...

int rand_bytes_read;
static int bNotFirstTime;
char buf[ 1024 ];

...

if(!bNotFirstTime) {
    SSLeay_add_all_algorithms();
    SSL_load_error_strings();
    ERR_load_crypto_strings();
    SSL_library_init();
    bNotFirstTime = 1;
}

/**** Code from ..., 10/3/2002 ****/
/**** Use /dev/urandom to seed if available  ****/
rand_bytes_read = RAND_load_file("/dev/urandom", 1024);
if (rand_bytes_read <= 0) {
    /* Couldn't read /dev/urandom, just seed off
     * of the stack variable (the old way)
     */
    RAND_seed(buf,sizeof buf);
}

In primo luogo, mi sembra che il modo corretto per verificare se RAND_load_file è riuscito è quello di verificare se i byte letti sono uguali ai byte richiesti.

Lasciando da parte, sono a mia conoscenza che SSL_library_init semina il PRNG da /dev/urandom se è disponibile, e da altre fonti su Windows ecc.

C'è un motivo per provare a ri-seminare il PRNG ogni volta che viene creato un nuovo contesto ( SSL_library_init è invocato solo la prima volta)?
Il contenuto di una variabile stack è accettabile per fornire casualità?

Wiki di OpenSSL afferma:

Initialization
OpenSSL will attempt to seed the random number generator automatically upon instantiation by calling RAND_poll. RAND_poll seeds the random number generator using a system-specific entropy source, which is /dev/urandom on UNIX-like operating systems, and is a combination of CryptGenRandom and other sources of entropy on Windows.

Be careful when deferring to RAND_poll on some Unix systems because it does not seed the generator. See the code guarded with OPENSSL_SYS_VXWORKS in rand_unix.c. Additionally, RAND_poll can have negative interactions on newer Windows platforms, so your program could hang or crash depending on the potential issue. See Windows Issues below.

PS: Crypt::SSLeay fornisce supporto per LWP :: UserAgent di Perl per comunicare su HTTPS. Non è più usato di default , ma è mantenuto in modo da non interrompere le impostazioni precedenti.

random openssl

posta Sinan Ünür 23.04.2014 - 15:53

fonte

1 risposta

Leggi altre domande sui tag random openssl

È brutto mettere un certificato come CA in Firefox? L'uso di jCryption 3.0 + SSL avrebbe mitigato la vulnerabilità Heartbleed?

score 2 · Accepted Answer

Con le versioni attuali e non correnti di OpenSSL, questo codice è inutile (ma innocuo), perché OpenSSL si posizionerà automaticamente su /dev/urandom su macchine in cui /dev/urandom è disponibile. Questo è documentato :

On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd() or RAND_load_file().

In realtà, la documentazione è leggermente errata perché su Windows, dove non c'è /dev/urandom , OpenSSL usa CryptGenRandom() , quindi il seeding automatico automatico continua a verificarsi.

Sulle macchine in cui non esiste un PRNG potente fornito dal sistema, il chiamante deve fornire "entropia" manualmente, ma questi sistemi sono, per definizione, macchine in cui non è presente /dev/urandom .

I contenuti di una variabile stack non inizializzata non sono certo una buona fonte di entropia, perché tali contenuti sono solitamente molto deterministici. Ragionevoli fonti di casualità in una macchina provengono dal "mondo fisico", in genere tempi precisi degli eventi hardware.