it-swarm.it

Quanto dovrebbe durare un nonce casuale?

NIST fornisce buone linee guida sulla lunghezza di chiavi e hash per vari algoritmi . Ma non vedo nulla di specifico sulla lunghezza di un casuale o pseudo-casuale nonce (numero usato una volta).

Se esiste un'unica buona risposta per una varietà di usi, mi piacerebbe vederlo. Ma per renderlo concreto, userò la comune situazione di "reimpostazione della password via e-mail", in cui il server genera un URL con un componente percorso pseudo-casuale. Sembra un po 'simile all'autenticazione Digest HTTP, in cui esempio nella RFC sembra avere 136 bit (dcd98b7102dd2f0e8b11d0f600bfb0c093).

Noto che molte persone sembrano usare gli UUID versione 4 (che forniscono 122 bit pseudo-casuali) o questo, come discusso in I GUID sono sicuri per i token una tantum? , sebbene l'utente debba fare attenzione all'uso delle precedenti versioni UUID molto più prevedibili e cattivi attacchi locali persistenti sul generatore di numeri casuali di Windows che erano principalmente rattoppato entro il 2008.

Ma ignorando la rischiosità di rimanere aggrovigliati nelle versioni e nelle implementazioni UUID, quanti bit pseudo casuali dovrebbero essere incorporati nell'URL?

35
nealmcb

Un nonce a 64 bit è probabilmente più che sufficiente per la maggior parte degli scopi pratici, se i 64 bit sono casualità di qualità crittografica.

Perché sono sufficienti 64 bit? Lasciami esporre il tipo di ragionamento che puoi utilizzare per rispondere a questa domanda. Presumo che si tratti di un URL a tempo limitato monouso; dopo che è stato usato una volta, non è più valido e dopo poco (3 giorni, diciamo), scade e non è più valido. Dal momento che il nonce è significativo solo per il server, l'unico modo in cui un utente malintenzionato può provare a indovinare è inviare l'indagine a 64 bit al server e vedere come risponde il server. Quante ipotesi può provare l'attaccante prima che scada il nonce? Diciamo che l'attaccante può fare 1000 richieste HTTP al secondo (è un attaccante piuttosto robusto); quindi l'attaccante può fare circa 1000 * 3600 * 24 * 3 = 228 ipotesi entro un periodo di 3 giorni. Ogni ipotesi ha un 1/264 possibilità di avere ragione. Pertanto, l'attaccante ha al massimo un 1/236 possibilità di infrangere lo schema. Questo dovrebbe essere più che abbastanza sicuro per la maggior parte delle impostazioni.

23
D.W.

Innanzitutto, stimare la quantità massima di utilizzi che il sistema otterrà (la quantità di volte in cui verrà generato un nonce casuale). Quindi, decidere su un livello di sicurezza accettabile, ovvero quanto deve essere improbabile che un nonce sia un duplicato di un vecchio. Calcola la quantità di usi in bit, raddoppia e aggiungi l'improbabilità di cui hai bisogno in bit e hai la tua lunghezza nonce.

Un esempio da AES-GCM con IV casuale. Il numero di invocazioni consentite con IV casuale per una determinata chiave è 232. La probabilità che un IV venga riutilizzato deve essere inferiore a 2-32. La lunghezza nonce richiesta per questo è 32 × 2 + 32 == 96 bit.

Se, ipoteticamente, vorresti essere in grado di generare 296 pacchetti, ognuno con un nonce casuale e vorrebbe che la probabilità di un nonce duplicato fosse inferiore a 2-32, avresti bisogno di un nonce lungo 96 × 2 + 32 == 224 bit.

Confrontando questo con la risposta sopra di 64 bit ... se ne hai più di 216 (65536) usi del sistema, la probabilità di avere un nonce duplicato in quel momento è superiore a 2-32 (più di 1 su 4 miliardi, scala ridotta). Questo potrebbe essere abbastanza accettabile, a seconda dei requisiti di sicurezza, oppure potrebbe non esserlo.

Come unica risposta adatta a tutti - gli UUID casuali menzionati sono una soluzione abbastanza buona.

Si noti che questi valori sono approssimazioni e i calcoli più accurati sono molto più complessi.

7
Nakedible