C'è un granello di verità in questo, in realtà più verità che mito, ma tuttavia l'affermazione riflette un fondamentale fraintendimento di ciò che sta accadendo. Sì, spostare il mouse durante la generazione di una chiave con GPG può essere una buona idea. Sì, spostare il mouse contribuisce all'entropia che rende casuali i numeri casuali. No, spostare il mouse non rende la chiave più sicura.
Tutti i buoni generatori casuali adatti alla crittografia, e quelli di Linux in quella categoria, hanno due componenti:
- Una fonte entropica , che non è deterministica. Lo scopo dell'entropia è di avviare il generatore di numeri casuali con dati imprevedibili. La fonte dell'entropia deve essere non deterministica: in caso contrario, un avversario potrebbe riprodurre lo stesso calcolo.
- Un generatore di numeri pseudocasuali , che produce numeri casuali imprevedibili in modo deterministico da uno stato interno in evoluzione.
L'entropia deve provenire da una fonte esterna al computer. L'utente è una fonte di entropia. Quello che l'utente fa per lo più non è casuale, ma i tempi precisi dei tasti e dei movimenti del mouse sono così imprevedibili da essere leggermente casuali - non molto casuali, ma a poco a poco, si accumulano. Altre potenziali fonti di entropia includono la tempistica dei pacchetti di rete e il rumore bianco della telecamera o del microfono. Diverse versioni e configurazioni del kernel possono utilizzare un diverso set di sorgenti. Alcuni computer hanno circuiti RNG hardware dedicati basati sul decadimento radioattivo o, in modo meno impressionante, circuiti elettronici instabili. Queste fonti dedicate sono particolarmente utili in dispositivi e server integrati che possono avere un comportamento abbastanza prevedibile al primo avvio, senza che un utente faccia cose strane.
Linux fornisce numeri casuali ai programmi tramite due dispositivi: /dev/randome/dev/urandom . La lettura da entrambi i dispositivi restituisce qualità crittografica. Entrambi i dispositivi utilizzano lo stesso stato RNG interno e lo stesso algoritmo per trasformare lo stato e produrre byte casuali. Hanno limiti particolari che non rendono nessuno dei due la cosa giusta:
/dev/urandom può restituire dati prevedibili se il sistema non ha ancora accumulato entropia sufficiente./dev/randomcalcola la quantità di entropia disponibile e blocca se non c'è abbastanza. Questo suona bene, tranne per il fatto che il calcolo si basa su considerazioni teoriche che fanno diminuire linearmente la quantità di entropia disponibile ad ogni bit di uscita. Quindi /dev/randomtende a bloccarsi molto rapidamente.
I sistemi Linux salvano lo stato RNG interno su disco e lo ripristinano all'avvio. Pertanto l'entropia si ripete da uno stivale all'altro. L'unica volta in cui un sistema Linux può non avere entropia è quando è appena installato. Una volta che c'è abbastanza entropia nel sistema, l'entropia non diminuisce; diminuisce solo il calcolo errato di Linux. Per ulteriori spiegazioni di questa considerazione, leggi /dev/urandomè adatto per generare una chiave crittografica , da un crittografo professionista. Vedi anche Puoi spiegare la stima entropica usata in random.c .
Lo spostamento del mouse aggiunge più entropia al sistema. Ma gpg può solo leggere /dev/random, non/dev/urandom (un modo per risolvere questo problema è creare /dev/randomlo stesso dispositivo 1: 9 /dev/urandom), quindi non è mai a rischio di ricevere numeri casuali non abbastanza casuali. Se non sposti il mouse, la chiave è il più casuale possibile; ma ciò che può accadere è che gpg può essere bloccato da una lettura /dev/random, in attesa che il contatore entropia del kernel aumenti.