Quanto dovrebbe durare un nonce casuale?

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

Perché 64 bit sono sufficienti? Permettetemi di definire il tipo di ragionamento che è possibile utilizzare per rispondere a questa domanda. Immagino che questo sia un URL a tempo limitato monouso; dopo che è stato usato una volta, non è più valido, e dopo un po 'di tempo (3 giorni, per esempio), scade e non è più valido. Poiché il nonce è significativo solo per il server, l'unico modo in cui un utente malintenzionato può provare a indovinare è inviare l'ipotesi a 64 bit al server e vedere come risponde il server. Quante supposizioni può provare l'attaccante nel tempo che precede il nonce? Diciamo che l'attaccante può fare 1000 richieste HTTP al secondo (che è un attaccante piuttosto energico); quindi l'attaccante può fare approssimativamente 1000 * 3600 * 24 * 3 = 2 ²⁸ in un periodo di 3 giorni. Ogni ipotesi ha una probabilità ⁶⁴ di avere ragione. Pertanto, l'attaccante ha al massimo una probabilità di rottura dello schema di 1/2 ³⁶ . Questo dovrebbe essere più che abbastanza sicuro per la maggior parte delle impostazioni.

In primo luogo, stimare la quantità massima di utilizzi che il sistema otterrà (la quantità di volte in cui un nonce casuale verrà generato). Quindi, decidete su un livello di sicurezza accettabile, ovvero quanto è improbabile che un nonce sia un duplicato di uno vecchio. Calcola la quantità di usi in bit, raddoppia quella e aggiungi l'improbabilità necessaria in bit e hai la lunghezza nonce.

Un esempio di AES-GCM con IV casuale. Il numero di invocazioni consentite con IV casuale per un determinato tasto è 2 ³² . 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, dovresti essere in grado di generare 2 ⁹⁶ pacchetti, ognuno con un nonce casuale e vorrebbe che la probabilità di un duplicato nonce sia inferiore a 2 ^-32 , avresti bisogno di un nonce che sia 96 × 2 + 32 == 224 bit di lunghezza.

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

Poiché una taglia unica si adatta a tutte le risposte, gli UUID casuali menzionati sono una soluzione abbastanza valida.

Nota che questi valori sono approssimazioni , e i calcoli più accurati sono molto più complessi.

Per la reimpostazione della password, per il token si usa un salt anziché un nonce. Cioè, è sufficiente generare un sale, memorizzarlo per un periodo di tempo associato all'account utente e attendere che l'utente faccia clic sul link con quel sale in esso. Non è necessario tenere traccia di questi token per assicurarsi che non vengano mai utilizzati più di una volta. Una volta utilizzato un token, è sufficiente eliminarlo.

Dovresti usare almeno 128 bit, generati da un generatore di numeri pseudo casuali crittograficamente strong. Non hai bisogno di un formato UUID - hai solo bisogno di una stringa cryptorandom sufficientemente lunga.

Per gli URL, puoi usare la codifica base64url o la codifica esadecimale. La codifica base64url sarà più breve, ma sarà sensibile al maiuscolo / minuscolo. La codifica base64url è leggermente diversa dalla codifica base64 in quanto non sono necessari = di terminazione e + e / vengono disattivati per - e _ , che i caratteri non devono essere appositamente codificato per URL.