Un'altra domanda noob, lo so, ma qualcosa di cui non sono sicuro.
Se in qualche modo conoscessi magicamente l'output di / dev / urandom in un dato momento, quanto avrebbe indebolito un determinato sistema di crittografia? O, forse, quali tipi di schemi di crittografia sarebbero più danneggiati riducendo questa casualità?
Se conoscessi l'output di /dev/urandom in qualsiasi momento e varie chiavi sono state generate utilizzando /dev/urandom (ad esempio chiavi private SSH / GPG o certificati SSL), in linea di principio potresti rapidamente (come in molto più rapidamente di brute- forza) ricreare una coppia di chiavi tentando di utilizzare vari stati di /dev/urandom . Ciò aggirerebbe efficacemente tutti i metodi di sicurezza in atto (crittografia dei file, https, protezione dell'integrità dei dati) basati su quelle chiavi ora danneggiate (questo attacco è esattamente identico all'ottenimento di chiavi / certificati privati di qualcuno).
Ci sono varie altre cose che si basano su / dev / urandom che potrebbero anche rompersi. Ad esempio, potresti completare un TCP handshake da un indirizzo IP che non controlli su un server con un crack / dev / urandom poichè potresti inviare un SYN, quindi inviare un ACK e indovinare il numero di sequenza del server.
Se non hai compromesso un sistema per sostituire / dev / urandom con qualcos'altro (o registrato i bit di / dev / random prima di usarli), l'urandom non è del tutto deterministico. / dev / urandom utilizzerà di default entropia raccolta da vari componenti hardware e ricadrà su un generatore pseudo-casuale solo quando è necessaria più entropia di quella che è stata raccolta.
La tua domanda è divertente, sono curioso di sapere come sei arrivato a chiedermi che / dev / urandom possa essere previsto.
Ma più di questo, questo solleva un difetto interessante, poiché Wikipedia lo menziona :
In 2004, Landon Curt Noll, Simon Cooper, and Mel Pleasant tested a variety of random number generators, including the /dev/random implementations in FreeBSD 5.2.1, Linux 2.4.21-20, Solaris 8 patch 108528-18, and Mac OS X 10.3.5.[7] They indicated that none of these /dev/random implementations were cryptographically secure because their outputs had uniformity flaws.
Detto questo, penso che risponda abbastanza bene alla tua domanda:
How much would that weaken a given encryption system?
Non posso dire quanto, ma posso dire che avrebbe un impatto abbastanza significativo da non considerarli come totalmente sicuri, perché "nessuna di queste implementazioni / dev / random era crittograficamente sicura".
Risposta ovvia: se la crittografia utilizza direttamente l'output di dev / urandom, allora gli evasore sapranno la tua chiave e potranno quindi decifrare il tuo ciphertext come fai con la tua chiave. Ovviamente hanno anche bisogno di conoscere il vettore di inizializzazione, che di solito è generato anche dall'output di dev / urandom.
Beh, ci sono molti schemi di crittografia ma se la tua chiave si basa su dev / urandom, allora tutti questi schemi saranno interessati se l'hacker conosce l'output del tuo dev / urandom ma non so come " misurare la forza "degli schemi di crittografia. Penso che un cryptalanyst possa rispondere.
Sulla casualità degli RNG di Linux, c'è un documento presentato a una conferenza IEEE: link I buchi di sicurezza e possibili attacchi sono discussi qui. Secondo il loro studio, dev / random e dev / urandom non sono "così tanto" sicuri.
D'altra parte, dev / random e dev / urandom possono superare test di casualità ma la vera casualità può essere ottenuta solo dalla meccanica quantistica: link
Leggi altre domande sui tag linux cryptography entropy