Usa USB TRNG come fonte di casualità per la generazione di chiavi OpenSSL

Usa /dev/[u]random sia alimentandolo con l'entropia del generatore di numeri casuali dell'hardware sia usandolo con qualsiasi consumatore di bit casuali che vuoi usare (anche OpenSSL si baserà su quelle interfacce). Il modo semplice è semplicemente convogliare l'input su / dev / random, ma questo non aumenterà il contatore di entropia (il driver dovrà registrarsi come fonte di entropia per farlo).

Il kernel mescolerà entropia da diverse fonti: interrupt a causa di input da tastiera e mouse, timing della rete e del disco rigido, ... Se aggiungi il generatore di numeri casuali dell'hardware, otterrai un mix di entropia da tutti quelli fonti. Alla fine, qualsiasi numero casuale con un numero costante aggiunto rimarrà casuale, quindi anche se il generatore di numeri casuali dell'hardware è completamente predeterminato, non romperà il generatore di numeri casuali.

Almeno, non appena è stata aggiunta abbastanza entropia da altre fonti: l'unica volta in cui potrebbe risultare in numeri casuali indovinabili è immediatamente dopo che il pool di numeri casuali non ha entropia sufficiente da altre fonti.

Raccomando vivamente di vedere la lezione di mezz'ora La semplice semplice realtà dell'entropia - O come Ho imparato a smettere di preoccuparmi e ad amare l'urandom tenuto al Chaos Communication Congress 2015, che ha un'ottima spiegazione di come i generatori di numeri casuali mischino diverse fonti di entropia. Spiega anche perché non dovresti preoccuparti troppo di /dev/random e del suo contatore di bit casuali, e usa invece /dev/urandom .

L'entropia di avvio insufficiente può portare a errori catastrofici di crittografia - leggi Estrazione di Ps e Q: rilevamento di chiavi deboli diffuse nei dispositivi di rete . Tuttavia, affidarsi a una fonte di entropia potenzialmente discutibile è solo un leggero miglioramento rispetto all'entropia insufficiente: si riduce solo un gruppo di persone che potrebbero potenzialmente compromettere il sistema. Fortunatamente, ci sono generatori di entropia open source solo software - uno di questi è CPU Time Jitter di Stephan Muller.

Tuttavia, a meno che tu non abbia un sistema headless con un SSD, perché credi che / dev / [random] non stia generando un'entropia adeguata? Nella maggior parte dei casi, il moderno kernel di Linux è abbastanza buono.

Come @ this.josh e risposte di tesi per una domanda simile suggerita: il comando rngd -r /dev/deviceId consente di aggiungere una nuova fonte (spesso un dispositivo hardware) per alimentare il pool di entropia.

Poiché la differenza principale tra /dev/random e /dev/urandom è rispettivamente il loro comportamento di blocco o non blocco quando le fonti di entropia non sono sufficienti , l'aggiunta di un dispositivo al pool di entropia con rngd rende /dev/random meno sicuro se il nuovo dispositivo collegato ha backdoor?

In altre parole fa rngd make /dev/random completamente fidato del nuovo dispositivo collegato fino a punto per non bloccarsi ad aspettare abbastanza entropia proveniente da altre fonti (come attività di rete, mouse e tastiera) e quindi impedisce che il suo output sia un mix di tutte le fonti di entropia disponibili sul computer? Se è il caso potrebbe essere un problema quando tutte le altre entropie non hanno creato abbastanza entropia mentre il mio generatore quantico lo ha fatto (dato che è producendo output casuali tutto il tempo) nel momento esatto in cui il mio programma ha chiamato /dev/random per generare coppie di chiavi, ad esempio: un utente malintenzionato che conosce i pattern ripetitivi del generatore quantico potrebbe facilmente intuire i numeri "casuali" utilizzati in quel momento dall'uscita non era un mix di tutte le fonti di entropia disponibili sul sistema.