Puoi spiegare la stima dell'entropia usata in random.c

/dev/randomusa i tempi delle interupts del kernel per aggiungere al pool di entropia. La quantità di entropia nel pool viene tracciata in una variabile denominata entropy_count.

Ecco il frammento di codice pertinente da random.c. Rappresenta il tempo (in jiffies credo) tra le ultime due interruzioni in variabile deltae le differenze in delta come delta2.

delta = time - state->last_time;
state->last_time = time;

delta2 = delta - state->last_delta;
state->last_delta = delta;

if (delta < 0) delta = -delta;
if (delta2 < 0) delta2 = -delta2;
delta = MIN(delta, delta2) >> 1;
for (nbits = 0; delta; nbits++)
  delta >>= 1;

r->entropy_count += nbits;

/* Prevent overflow */
if (r->entropy_count > POOLBITS)
  r->entropy_count = POOLBITS;

Sembra che la stima dell'entropia aggiunta sia essenzialmente il floor (non il ceil a causa del bitshift iniziale prima del loop) del logaritmo di base 2 del delta. Questo ha un senso intuitivo, anche se non sono sicuro di quali ipotesi sarebbero necessarie per renderlo formalmente corretto.

Quindi, la mia prima domanda è "qual è il ragionamento alla base di questa stima?"

La mia seconda domanda riguarda delta = MIN(delta, delta2) .... Cosa fa questo? Perché prendere il minimo di questo delta e l'ultimo? Non so che cosa dovrebbe raggiungere - forse rende la stima migliore, forse solo più conservativa.

Modifica: ho trovato un documento che specifica la stima , ma in realtà non fornisce un argomento motivato (sebbene delinei alcune condizioni informali che lo stimatore dovrebbe soddisfare).

Altre risorse che sono emerse nei commenti:

• Wikipedia su /dev/randome/dev/urandom
• Un documento che cerca di spiegarlo (sono scettico al riguardo, vedi commenti)
• Un post sul blog/dev/random con commenti del ragazzo che ha scritto il codice sopra.
• Una risposta secutity.SE sul /dev/randompool di entropia.

delta2non è il precedente delta, ma la differenza tra due valori successivi di delta. È una specie di derivata: se deltamisura la velocità, delta2è l'accelerazione.

L'idea intuitiva alla base di tale stima è che gli interruzioni si verificano a intervalli più o meno casuali, dettati da eventi imprevedibili del mondo fisico (ad esempio, battute di tasti o arrivo di pacchetti di rete). Più lungo è il ritardo, più eventi imprevedibili sono coinvolti. Tuttavia, ci sono sistemi fisici che sparano interrompono a una velocità fissa; la delta2misura è un meccanismo di protezione che rileva tali occorrenze (se si verificano interruzioni a intervalli fissi, quindi decisamente prevedibili, tutti deltaavranno lo stesso valore, quindi delta2saranno zero).

Ho detto "intuitivo" e non c'è molto altro da dire. In effetti, nel modello "eventi fisici casuali", il conteggio dei bit è errato; se si verifica un evento hardware con probabilità p per ogni unità di tempo e si ottiene un ritardo espresso su n bit, il contributo entropico deve essere considerato come n / 2 bit, non n bit. Ma sappiamo che in realtà gli eventi fisici non si verificano in momenti esattamente casuali; il delta2meccanismo ammette altrettanto.

Quindi, in pratica, la "stima dell'entropia" è esattamente questo: una stima . Il suo valore di sicurezza non deriva da una giustificazione ragionata, matematicamente esatta, ma dalla solita fonte di sicurezza: nessuno sembra aver trovato un modo per abusarne (ancora).

Questa pagina è stata scritta da qualcuno che si è stufato dei miti /dev/randome del suo stimatore entropico, e penso che spieghi bene le cose, con dettagli sufficienti. È importante avere alcune idee di base quando si tratta di RNG.