Quanto sono negative le macchine virtuali (vms) in / dev / urandom?

Question

Quanto sono negative le macchine virtuali (vms) in / dev / urandom?

#1 da (6 voti)

2

Ho esaminato le domande qui e qui .

Questo ha suscitato il mio interesse mentre recentemente sono stato coinvolto nell'osservazione della conformità FIPS e nel mio ambiente vm / dev / urandom test di conformità genera dati come questo:

[admin@xxx~]$ cat /dev/urandom | rngtest -c 5000
rngtest 2
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 100000032
rngtest: FIPS 140-2 successes: 4998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.210; avg=63.902; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=2.477; avg=123.448; max=157.632)Mibits/s
rngtest: Program run time: 2277143 microseconds

La cosa che manca a queste domande è come cattivo è cattivo? Abbiamo numeri fissi che dettano conformità statistica?

Quanto male trasferirsi in una macchina virtuale danneggia entropia?

linux cryptography encryption entropy fips

posta avgvstvs 17.10.2014 - 21:22

fonte

1 risposta

Leggi altre domande sui tag linux cryptography encryption entropy fips

Qual è l'accordo con i certificati radice SSL Valicert? Perché proteggere i file con informazioni sensibili con .htaccess?

score 6 · Accepted Answer

I test statistici come quello che usi non possono rilevare se /dev/urandom è buono o cattivo su una macchina specifica.

In particolare, /dev/urandom esegue un PRNG crittograficamente protetto . Da un dato stato interno iniziale (il "seme"), produce un flusso arbitrariamente lungo di byte apparentemente casuali. Il PRNG essendo crittograficamente sicuro significa che per un utente malintenzionato in realtà prevedere il prossimo bit con probabilità migliore di 1/2, DEVE aver indovinato lo stato interno esatto (fino all'ultimo bit); altrimenti, non ha niente.

Il rischio di /dev/urandom in una VM si riferisce alla possibilità teorica di essere in grado di indovinare tale stato, poiché lo stato è alimentato da fonti hardware e una VM non ha un vero hardware, solo hardware emulato. Tuttavia, questo richiede un aggressore intelligente che sappia perfettamente che il PRNG è quello usd di /dev/urandom su questa specifica macchina, e l'attaccante cerca intenzionalmente potenziali stati interni sulla base di ciò che sa sull'hardware emulato e su ciò che il sistema operativo estrae come " seme casuale "da quell'hardware. Il tuo rngtest non fa nulla del genere; esegue test statistici di base per vedere se ci sono pregiudizi in un flusso di 100 Mbits.

Riassumendo: rngtest non verifica la cosa importante, ovvero quanto il seme è difficile da indovinare da un aggressore intelligente. Invece, rngtest misura quanto bene l'algoritmo PRNG crittograficamente sicuro sia effettivamente crittograficamente sicuro; e lo fa solo fondamentalmente (non può vedere nulla tranne i pregiudizi più evidenti). Per natura, rngtest non può rilevare alcun problema relativo alla VM con /dev/urandom (e, corrispondentemente, è abbastanza inutile eseguirlo).