Vale la pena aumentare l'entropia / dev / random nel software?

La risposta breve è che l'invio di /dev/random indietro con l'output di /dev/urandom non ridurrà la sicurezza. Per rendere le cose più chiare (i commenti indicano che non ero abbastanza preciso), il mio punto è che l'alimentazione di /dev/random con l'output di /dev/urandom è innocua (sebbene non aumenta sicurezza); è anche piuttosto inutile (eccetto come un modo per supportare facilmente le applicazioni che insistono nell'usare /dev/random e bloccare inopportune volte senza una buona ragione).

Per semplificare le cose, definiamo un modello funzionante del funzionamento di /dev/random e /dev/urandom :

• C'è uno stato interno p che consiste in k byte (per alcuni interi k ).
• È stata iniettata un'ulteriore entropia x sostituendo p con H ( p , x ), dove H è una "sorta di" funzione di hash. Ad esempio, lo stato corrente è concatenato con la nuova entropia, il risultato viene sottoposto a hash e l'output hash è il nuovo p .
• L'output viene prodotto usando p come input per un CSPRNG ; i primi k byte sono il nuovo valore di p e i byte successivi sono l'output per quella esecuzione.
• /dev/random differisce da /dev/urandom in quanto occasionalmente rifiuta di produrre byte finché non viene iniettata nuova entropia (o raccolta dall'hardware).

(Quanto sopra è un modello concettuale che è abbastanza vicino all'attuazione reale ai fini della discussione attuale).

La sicurezza dell'intera cosa dipende dall'entropia di p ; grosso modo, su quanto p è sconosciuto agli aggressori. Gli hacker sanno che p ha dimensioni k , quindi possono provare a indovinare p per forza bruta, che ha un costo di circa 2 ^{8 k -1} in media. Il CSPRNG è considerato crittograficamente sicuro perché l'analisi di molti byte dell'output non produce informazioni su altri byte di output - in particolare, non fornisce informazioni su p (sia prima o dopo la corsa).

Supponiamo ora che x sia scelto dall'attaccante. Finché H si comporta come una funzione di hash sicura, H ( p , x ) ha la stessa entropia di p - l'utente malintenzionato non ha ancora informazioni su p dopo l'operazione. A rigor di termini, può esserci un effetto di "riduzione dello spazio", fino a circa la dimensione 2 ^{8 k / 2} se l'attaccante è autorizzato a eseguire il trucco "entropy feeding" 2 ^{8 k / 2} volte. Se k è abbastanza grande (ad esempio 32, per uno stato interno a 256 bit), lo spazio rimanente è ancora abbastanza grande per la sicurezza, e comunque questa situazione non può essere raggiunta .

Poiché CSPRNG non fornisce informazioni su p , l' output di quel CSPRNG non può essere peggiore per la sicurezza di un x controllato da un aggressore . Questa è la parte che sarebbe più difficile da formalizzare in un modo accademico (ci vorrebbero poche pagine per scriverlo correttamente). Intuitivamente, il CSPRNG, quando si usano k byte di input e prendendo k byte di output, si comporta come un oracolo casuale.

Pertanto, l'invio di /dev/random dall'output di /dev/urandom non ridurrà la sicurezza.

Ciò dipende ovviamente dall'idea che la funzione di aggiornamento dello stato (per l'iniezione di entropia) e il CSPRNG siano entrambe funzioni "ideali". Se non lo sono, allora sei condannato comunque (il comportamento autobloccante di /dev/random non ti salverà in quel caso).

Sfortunatamente alcune delle persone che preferiscono /dev/random sono FIPS e Common Criteria. [EDIT: Non riesco a trovare una citazione per questo, ma vedi in fondo per una fonte non ufficiale] Quindi, se vuoi che il tuo software sia certificato FIPS / CC, non può usare /dev/urandom . deve dimostrare che mantiene una stima precisa della sua entropia e che deve bloccare quando l'entropia è bassa.

Breve background:

Tutti i generatori di numeri casuali deterministici sono solo casuali come i loro semi. Entropia è una stima di quanto sia casuale (o inatteso o imprevedibile ) il tuo seme. Per aumentare l'entropia del tuo RNG, devi mescolare la casualità da una fonte esterna. Se hai accesso a fonti di dati imprevedibili (spesso temporali su dispositivi di input umani o rumore termico), quindi, immettili in /dev/random per aumentare l'entropia del seme.

Il kernel Linux mescolerà automaticamente tutte le fonti di casualità a cui ha accesso, tempistica dei pacchetti, tempistica delle sequenze di tasti, casualità dallo scheduler del processo, generatori di numeri casuali hardware collegati (che stanno iniziando a essere inclusi nelle schede madri dei consumatori) ). Quindi è grandioso.

L'unico caso di cui sono a conoscenza dove /dev/random è noto per essere debole è su macchine virtuali senza testa dove non c'è letteralmente nulla da sfruttare per l'imprevedibilità.

Bene, passiamo alla domanda attuale:

I want to be certain that using a daemon like rngd or haveged to work randomness back into /dev/random - even if they're based on /dev/urandom like rngd would be in most cases - doesn't introduce weaknesses.

La mia domanda è: dove sono rngd , haveged e /dev/urandom che ricavano la loro casualità? È veramente nuova casualità proveniente dall'esterno della macchina, o è solo un re-hash di /dev/random ?

Non posso parlare con rngd o haveged , ma so che su Linux /dev/urandom condivide un RNG con /dev/random (vedi this awesome rant , da cui ho preso in prestito un'immagine sotto), e su FreeBSD /dev/urandom è letteralmente un puntatore a /dev/random , quindi con ogni probabilità stai solo restituendo /dev/random a se stesso.

Non sono un esperto abbastanza per sapere se questo introduce punti deboli o meno, ma certamente non sta andando bene.

L'unicamenzionedi"no / dev / urandom" che posso trovare nei documenti FIPS è una bozza del 2014 che non è mai stata pubblicata. Includeva la nota a piè di pagina:

Note2: The /dev/urandom generator is assumed to provide no entropy unless it is specifically instrumented to ensure a minimum of 112-bits of available entropy at all times.

Quindi procede elencando i modi in cui è possibile garantire l'entropia. Questo è molto meno rigido di quanto fossi stato indotto a credere. Cool, oggi ho imparato!

Non fare cose di pesce con l'alimentazione di dati di hogwash in / dev / random ecc. Se lo desideri, puoi sostituire / dev / random con un link simbolico a / dev / urandom

Puoi usare haveged o qualcosa del genere, ma non usare nulla senza alcun input esterno. (anche, specialmente con havaged , fare attenzione se si esegue l'hardware virtualizzato)

/ dev / random è abbastanza robusto contro l'input con una cattiva entropia, ma se lo alimenti troppe cose senza senso, chissà cosa succede?

/ dev / urandom è ben noto e testato. Se colleghi link / dev / random ad esso, probabilmente non avrai problemi. Se fai cose di pesce, potresti avere problemi!

Inoltre: di cosa vorresti essere responsabile: "La prima connessione sicura al nostro server dopo il riavvio richiede quasi un secondo !!!" / "Generare molti certificati è lento" o "La cosa che hai fatto con il nostro tutte le nostre chiavi sono rotte, tutti i nostri dati vengono rubati! COSA HAI FATTO? "

Decidete saggiamente!