it-swarm.it

Un Rand di / dev / urandom è sicuro per una chiave di accesso?

Diciamo che voglio creare un cookie per un utente. Generando semplicemente una stringa da 1024 bit usando / dev/urandom , e controllando se esiste già (eseguendo il ciclo fino a quando non ottengo unico) è sufficiente?

Dovrei generare la chiave in base a qualcos'altro? Questo è incline a un exploit in qualche modo?

187
Incognito

La risposta breve è sì. Anche la lunga risposta è sì. /dev/urandom fornisce dati indistinguibili dalla vera casualità, data la tecnologia esistente. Ottenere casualità "migliore" rispetto a ciò che /dev/urandom fornisce non ha senso, a meno che tu non stia utilizzando uno dei pochi algoritmi crittografici "teorici dell'informazione", che non è il tuo caso (lo sapresti).

La pagina man di urandom è alquanto fuorviante, probabilmente decisamente sbagliata, quando suggerisce che /dev/urandom può "rimanere senza entropia" e /dev/random dovrebbe essere preferito; l'unico istante in cui /dev/urandom might implica che un problema di sicurezza a causa della bassa entropia è durante i primi momenti di una nuova installazione del sistema operativo automatizzata; se la macchina si è avviata al punto in cui ha iniziato ad avere qualche attività di rete, allora ha raccolto abbastanza casualità fisica per fornire casualità di qualità abbastanza alta per tutti gli usi pratici (sto parlando di Linux qui; su FreeBSD, quell'istante momentaneo di lieve la debolezza non si verifica affatto). D'altro canto, /dev/random ha la tendenza a bloccarsi in momenti inopportuni, portando a problemi di usabilità molto reali e fastidiosi. Oppure, per dirlo in meno parole: usa /dev/urandom e sii felice; uso /dev/random e dispiace.

( Modifica: questa pagina Web spiega le differenze tra /dev/random e /dev/urandom piuttosto chiaramente.)

Ai fini della produzione di un "cookie": tale cookie dovrebbe essere tale che nessun utente condivida lo stesso cookie e che sia computazionalmente impossibile per chiunque "indovinare" il valore di un cookie esistente. Una sequenza di byte casuali lo fa bene, a condizione che utilizzi casualità di qualità adeguata (/dev/urandom va bene) e che è abbastanza lungo. Come regola generale, se hai meno di 2n utenti ( n = 33 se l'intera popolazione della Terra potesse usare il tuo sistema), allora una sequenza di n + 128 bit è abbastanza ampia ; non devi nemmeno verificare una collisione con valori esistenti: non lo vedrai nella tua vita. 161 bit si inserisce in 21 byte.

Ci sono sono alcuni trucchi che sono fattibili se vuoi biscotti più corti e desideri comunque evitare di cercare collisioni nel tuo database. Ma questo non dovrebbe essere necessario per un cookie (presumo un contesto basato sul Web). Inoltre, ricorda di mantenere riservati i tuoi cookie (ovvero usa HTTPS e imposta i cookie "sicuri" e "HttpOnly").

222
Thomas Pornin

Sì, è un ottimo modo.

@ La spiegazione di Thomas lo inchioda. Ed ha perfettamente ragione a criticare il /dev/urandom pagina man. Spot on.

Ma salta "verifica se esiste già". Quel controllo è inutile. Non succederà. (Le probabilità che ciò accada sono inferiori alla probabilità di essere colpiti da un fulmine - più volte - nello stesso giorno.)

25
D.W.

Fai attenzione ai casi Edge se stai usando Linux o NetBSD.

Su Linux, ti consigliamo di assicurarti di aver acquisito abbastanza entropia dopo l'avvio per eseguire correttamente il seeding del CSPRNG o utilizzare la chiamata di sistema getrandom() da leggere da /dev/urandom e blocca solo nel raro caso in cui non sia disponibile un'entropia iniziale iniziale post-avvio sufficiente.

In NetBSD, vorresti leggere da /dev/random almeno una volta prima di leggere da /dev/urandom per assicurarsi che sia stato seminato correttamente.

Su FreeBSD e MacOS non c'è differenza tra /dev/random e /dev/urandom.

La risposta breve deve ancora utilizzare /dev/urandom.

Vedi Quando usare/dev/random vs/dev/urandom per ulteriori dettagli.

1
Tom Hale