Quanto più sicura è la crittografia se il programma richiede un input casuale dall'utente?

Sostanzialmente zero.

I sistemi operativi integrano già ogni fonte di casualità potenziale su cui possono mettere le mani per seminare le loro API di casualità (esempi CryptGenRandom() su Windows, /dev/urandom su varianti POSIX, getrandom(2) su Linux e getentropy(2) su FreeBSD). Queste fonti includono i movimenti del mouse, i tempi del disco e altri eventi imprevedibili.

Il fatto è che, una volta raggiunto un certo punto - diciamo 256 bit di entropia raccolta, che richiede in pratica meno di qualche secondo - il sistema operativo può generare un flusso effettivamente illimitato di numeri casuali imprevedibili per la durata residua del sistema. Molti sistemi operativi salvano anche questo stato interno al riavvio, impedendo la necessità di reinizializzare il generatore casuale di numeri casuali da zero. Più entropia a quel punto non ti dà più imprevedibilità e raccogliere i movimenti del mouse è già fatto come parte di questo processo comunque .

L'entropia aggiuntiva consente al sistema operativo di recuperare dall'esposizione teorica o dalla contaminazione del suo stato casuale interno, ma è molto improbabile che ciò si verifichi nella pratica su una macchina non compromessa.

To my knowledge the typical way of doing this is to use the computer time as the seed to the random number generator…

Nessun RNG crittograficamente sicuro utilizza l'orologio di sistema per questo scopo. Come sottolinea @CBHacking, questa è una fonte estremamente debole di numeri casuali, poiché "che ora è" è altamente prevedibile (e talvolta facilmente influenzabile da fonti esterne). Anche le temporizzazioni a livello di microsecondi di input umani possono essere semi-prevedibili, ma raccogliere e mescolare ripetutamente questi dati può fornire molto velocemente una buona fonte di entropia. Le moderne funzioni di missaggio RNG sono ottime per estrarre e combinare anche piccole quantità di entropia.

TL; DR:

Nessuno, davvero. I computer moderni generano entropia di alta qualità ("casualità", in sostanza) abbastanza veloce da rendere irrilevante il tuo mouse.

Maggiori dettagli:

Programmi come Truecrypt (e possibilmente versioni precedenti di cose come ssh-keygen , gpg , e così via) che ti dicono di fare cose durante la generazione di chiavi stanno operando supponendo che il SO non possa avere fonti di entropia molto veloci a parte l'interazione dell'utente e / o un entropy pool molto piccolo per il suo generatore di numeri pseudo-casuali crittograficamente sicuro (CSPRNG). Sui vecchi computer, soprattutto senza connessioni Internet o risorse sufficienti per eseguire molti processi in background, questo era probabilmente vero almeno una volta.

I computer moderni sono piuttosto bravi nella generazione di entropia e dispongono di pozze di entropia relativamente grandi che possono facilmente sparare abbastanza fosse per generare una chiave. Inoltre, in questi giorni è comune utilizzare CSPRNG che supportano l'entropia di stretching (su sistemi operativi * nix, questa sarebbe la differenza tra /dev/random , che viene prelevata direttamente dal pool di entropia e /dev/urandom che può richiedere una piccola quantità di entropia dal pool e usarlo per generare un gran numero di bit leggermente meno casuali; /dev/urandom è, sui sistemi operativi moderni, ancora generalmente abbastanza buono per la generazione delle chiavi). È ancora teoricamente possibile finire con macchine che dispongono di pool di entropia del kernel prevedibili (un gruppo di macchine virtuali identiche che girano su identiche macchine headless con identiche versioni di software avviate contemporaneamente, ecc. A volte possono avere inizialmente la stessa entropia del kernel), ma è non facile. Questo è il motivo per cui i moderni host VM hanno il modo di alimentare alcune entropie ai guest VM in base agli stati dell'hardware, ecc. Che di solito vengono utilizzati nella generazione di entropia del kernel in questi giorni.

La maggior parte delle CPU moderne ha persino la quantità di RNG hardware basata su cose come lo stato termico delle diverse parti del chip della CPU, che variano rapidamente a seconda di cose come esattamente quali istruzioni sono state eseguite di recente e se hanno causato errori di cache o non, minuscole variazioni di tensione dall'alimentazione, movimento dell'aria nella stanza e altre cose del genere; le differenze sono minime, ma nel loro insieme c'è molta entropia e la CPU ha hardware dedicato per la raccolta e nuovi opcode per fornirlo al sistema operativo. Molti SO lo mischiano nel loro pool di entropia del kernel, insieme ad altri input, rendendo molto difficile esaurire l'entropia con normali carichi di lavoro "utente" su un PC moderno.

IMPORTANTE:

Non esiste CSRPNG nel mondo che sia stato seminato in modo significativo dall'orologio di sistema! Il motivo è semplice. Sembra che tu pensi che il tempismo "al millisecondo" sia sufficientemente casuale per la crittografia, ma ti stai sbagliando. Prendiamo qualcosa come la generazione di una coppia di chiavi GPG come esempio. Quelli generalmente hanno un periodo di validità sulle loro chiavi pubbliche, che mi dice (ho la tua chiave pubblica, dopo tutto è pubblico) quando la chiave è stata generata, al giorno. Ci sono 86400000 ms in un giorno (ignorando il fatto che probabilmente posso restringere un lotto considerando ore in cui una persona rischia di essere sveglia). Log2 (86400000) è 26,36 bit. La tua coppia di chiavi RSA 4096-bit presumibilmente super-sicura ha effettivamente meno entropia di una password di buona qualità! La forzatura bruta di 86400000 diverse coppie di chiavi possibili per trovare la chiave privata corrispondente richiederà un po 'di tempo, ma molto meno tempo rispetto al tentativo di calcolare una chiave pubblica RSA 4096-bit. Infatti, non ci sono abbastanza millisecondi dagli albori dell'informatica elettronica per produrre una chiave DES completamente casuale (56 bit), scegliendo tra di loro, e siamo in grado di forzare la DES bruta in meno di un giorno usando il normale scaffale. hardware ( sì, la generazione di chiavi RSA richiede molto più lavoro rispetto a prendere solo 56 bit e calcolare la loro parità per la generazione di chiavi DES, ma è ancora abbastanza veloce per questo scopo ).

Invece, qualsiasi programma di crittografia che non sia puramente inutile garbage (e alcuni lo sono) usa un CSPRNG (come /dev/urandom su sistemi di tipo Unix, o CryptGenRandom() su Windows) per la generazione delle chiavi. Allo stesso modo, la maggior parte delle librerie standard del linguaggio di programmazione include almeno due PRNG: uno veloce ma insicuro per cose in cui non importa se qualcuno potrebbe teoricamente prevedere l'output (in Java, questo è java.util.Random ), e crittograficamente sicuro uno, di solito o seminato da o direttamente solo restituendo l'output del sistema operativo CSPRNG, per cose come crypto (in Java, questo è java.security.SecureRandom ). Nessun PRNG seminato dall'ora corrente, indipendentemente dall'algoritmo che utilizza, potrebbe mai essere considerato crittograficamente sicuro; lo spazio di ricerca è troppo piccolo.