Python's pythonto library per generazione di numeri casuali vs os.urandom

Question

Stavo cercando di capire e capire se dovrei usare os.urandom() o Crypto.Random.new() per i numeri pseudo-casuali crittograficamente sicuri.

Il seguente sito web sembra suggerire di utilizzare os.urandom():

https://github.com/mozilla/PyHawk/pull/13

ma io non vedo proprio il motivo per cui e gli altri siti che ho trovato on-line in realtà non spiegano quale usare.

Se qualcuno sa quale è sicuro per l'uso crittografico, gradirei il consiglio!

Una delle cose che mi preoccupano in particolare è che, ho intenzione di usarlo per generare numeri casuali ma sono preoccupato che un giorno generi dei numeri casuali e il giorno dopo lo stato del generatore è lo stesso e inizia a generare gli stessi numeri "casuali".

Answer 1

Nel link che hai dato, la ragione solo dato a preferire urandom() è che ha tirato meno codice in (il sistema operativo implementa la "maggior parte di esso", e os.urandom() è costruito in Python).

Se si distribuisce un pacchetto Python, è possibile semplificare la vita degli utenti riducendo al minimo le dipendenze esterne. Questo è l'intero punto del collegamento che hai trovato.

In termini di qualità, in entrambi i casi dovrebbe funzionare correttamente. Preferisco urandom() perché capisco cosa fa; Non ho mai scavato nelle viscere di PyCrypto. Ma urandom() è stato criticato per l'uso negli ambienti alcuni. Click this e scorrere verso il basso per la parte che inizia

Gutterman, Pinkas, & Reinman marzo 2006 ha pubblicato una dettagliata analisi crittografica del generatore di numeri casuali Linux ...

Answer 2

urandomfa restituiscono i numeri crittograficamente protetti, con un avvertimento. Se esaurisce l'entropia (dati casuali reali generati dal movimento del mouse, fluttuazioni della temperatura della CPU su Ivy Bridge + chip, ecc.), Inizierà a produrre numeri pseudo-casuali meno sicuri. Questi sono generati da un forte generatore, ma a seconda dell'applicazione potrebbero non essere abbastanza casuali. Sui sistemi Unix, /dev/random si bloccherà mentre attende più entropia, mentre /dev/urandom inizierà a generare numeri pseudo-casuali.

Non sono esperto su PyCrypto, tuttavia leggendo la fonte, sembra che lo Crypto/Random/OSRNG/posix.py si legge semplicemente da /dev/urandom - quindi non mi preoccuperei troppo della scelta.

Answer 3

vado per os.urandom. In tutte le (recenti) implementazioni Python che ho controllato, fa la cosa giusta semplicemente aprendo una connessione senza buffer /dev/urandom o il dispositivo equivalente su altre piattaforme non Linux.

D'altra parte, Crypto.Random di PyCrypto è un wrapper molto complesso basato su Fortuna. Tale costruzione complessa è stata probabilmente realizzata nella speranza di mitigare alcuni difetti del sistema operativo sottostante.Purtroppo:

• Tira ancora entropia da /dev/urandom (su Linux), quindi se il sistema operativo è rotto, pycrypto di Crypto.Random sarà spezzato troppo (sconfiggendo il suo scopo)
• Tale scelta ha fallito, dal momento che è molto difficile occuparsi del biforcarsi e dei casi in cui la stessa entropia viene riutilizzata da processi diversi (vedere CVE-2013-1445).
• Il codice Fortuna non è coperto affatto dai test unitari e l'algoritmo Fortuna stesso non viene fornito con i vettori di prova. Questo da solo ti costringe a fare un (grande) salto di fede.