Sarebbe sicuro generare un numero casuale usando AES?

Quello che stai descrivendo è un PRNG basato su AES. Crittografia dei valori successivi di un contatore con AES e una chiave segreta è un metodo audio per la creazione di un PRNG (infatti, equivale a crittografare una lunga sequenza di zeri con AES / CTR), a condizione di cura di quanto segue:

• Devi usare il codice a blocchi "così com'è": codifica il contatore come un singolo blocco da 16 byte, elaboralo con AES (nessuna "modalità di cifratura a blocchi"), ottieni i 16 byte pseudocasuali successivi. Incrementa il contatore e loop.

• Questo non sarà più strong di quanto la chiave di crittografia sia segreta. Mantieni la chiave al sicuro!

• Naturalmente questo presuppone che tu abbia già una chiave segreta, il che implica che a un certo punto sia stato utilizzato un altro PRNG crittograficamente sicuro. Un PRNG non crea casualità, espande un po 'di casualità iniziale (il "seme", qui il tasto AES) in un lungo flusso di byte pseudocasuali.

• Questo PRNG si basa sul mai che riutilizza un valore contatore. Quindi devi assicurarti che il contatore sia sempre aumentato e non possa essere forzato a "riavvolgere". Questo non è così facile come sembra, in particolare nei dispositivi embedded, dove la memorizzazione permanente in lettura-scrittura è molto importante e l'utente (che potrebbe essere l'autore dell'attacco) può forzare le reimpostazioni hardware in qualsiasi momento (rimuovendo la batteria).

• AES è un codice a blocchi, è una permutazione dello spazio dei valori di blocco. Come tale, non produrrà mai due volte lo stesso blocco da 16 byte, che si discosta da ciò che una vera sorgente casuale produrrebbe. Questo può iniziare a mostrare (statisticamente) dopo circa 2 ⁶⁸ byte, che è abbastanza alto da non costituire un problema. Tuttavia, pensaci due volte prima di provare lo stesso trucco con un codice a blocchi con blocchi più piccoli (3DES, Blowfish ...).

Un miglioramento potrebbe essere quello di rigenerare una nuova chiave AES ogni volta che il server si avvia, usando /dev/urandom . In questo modo, non vi è alcuna chiave per archiviare ovunque. In effetti, non è necessario riutilizzare sempre la stessa chiave.

(Probabilmente, è ancora più semplice usare il PRNG strong che è già presente, ad esempio /dev/urandom . Passare a un PRNG personalizzato come quello che si immagina è abbastanza ingiustificato; a meno che ti occorrono pseudocasuali byte a più di 10 megabyte al secondo, che può succedere in alcuni casi, ma è strano. Se hai bisogno di lotti di byte pseudocasuali, potresti prendere in considerazione l'uso di altri algoritmi più specializzati come < a href="http://www.ecrypt.eu.org/stream/"> questi codici di flusso .)

In teoria, sì, ma ci sono preoccupazioni pratiche.

Come generatore di numeri pseudocasuali, funziona abbastanza bene. Ma per farne un CSPRNG, dovresti iniziare con una chiave casuale crittograficamente sicura ... e per ottenere una chiave casuale protetta da crittografia, hai bisogno di un CSPRNG. Questo è un problema di pollo e uova: per costruire un CSPRNG su AES, devi già avere un CSPRNG.

Perché lo faresti? Nella maggior parte dei casi, non avrebbe molto senso: se hai accesso a un CSPRNG per creare la tua chiave, allora potresti anche usarla direttamente. Tuttavia, ci sono ancora casi in cui può essere utile. Ad esempio, se stai codificando in una situazione in cui non hai accesso a un CSPRNG, ma fai hai accesso a una chiave segreta creata con una (e sai che questa chiave è stato tenuto al sicuro), quindi è possibile utilizzare AES per creare numeri casuali protetti da crittografia dalla chiave. Tuttavia, i problemi di implementazione citati in altre risposte sono ancora validi.

Penso che l'output dovrebbe sembrare piuttosto casuale. Ma è, comunque, l'ID molto prevedibile che la tua chiave privata è conosciuta. Quindi i numeri generati hanno pochissima entropia. Chiamerei il risultato un PRNG ma mai un SPRNG o un CSPRNG.