La stessa domanda di È un rand da / dev / urandom secure per un tasto di accesso , ma con la funzione rand di glibc anziché /dev/urandom . E quale sarebbe un generatore di semi sufficientemente sicuro?
La stessa domanda di È un rand da / dev / urandom secure per un tasto di accesso , ma con la funzione rand di glibc anziché /dev/urandom . E quale sarebbe un generatore di semi sufficientemente sicuro?
No. Il PRNG nelle tipiche librerie C è progettato per la velocità, non per la sicurezza. Di solito è appropriato per simulazioni numeriche e giochi (in implementazioni di buona qualità - ci sono implementazioni là fuori, per lo più vecchie, dove non è appropriato per nulla), ma non per la crittografia. Un PRNG crittografico deve essere imprevedibile, ovvero un utente malintenzionato che genera una serie di numeri non deve essere in grado di fare una buona indovina al prossimo numero. La tipica libreria C PRNG si impegna per la velocità e le buone proprietà statistiche ma non per l'imprevedibilità.
A partire da Glibc 2.7, rand e amici usano un lineare PRNG congruenziale o un registro spostamento lineare feedback a seconda della lunghezza seme disponibile.
Per generare materiale chiave o qualsiasi altro numero casuale coinvolto nella crittografia (comprese cose non segrete come nonce che tuttavia devono essere imprevedibili), ottenere tutti i bit da un RNG di qualità crypto. Il /dev/urandom di Linux (o qualsiasi altro unix che ha /dev/urandom ) va bene per quello. Devi usarlo per ogni byte di ogni chiave; usarlo come seme della libreria C PRNG non è buono (ci sarebbe una strong correlazione tra le chiavi). Una libreria come OpenSSL è un'altra scelta; probabilmente utilizzerà /dev/urandom sotto il cofano come seme, ma potrebbe essere un po 'più veloce se generi grandi volumi di dati casuali.
No! rand() è totalmente insicuro. L'utilizzo di rand() per questo scopo ha causato principali vulnerabilità nei principali sistemi .
Usa solo /dev/urandom .
Leggi altre domande sui tag linux random authentication