Número aleatório no Linux

Question

No linux / dev / random é baseado em "variáveis ambientais" e / dev / urandom é baseado em um algoritmo e no tempo. Minhas perguntas são:

Onde o / dev / random coleta essas variáveis de.

E se você tiver duas máquinas configuradas para o mesmo tempo (até o milissegundo - se possível) e tiver a mesma velocidade, sistema operacional, etc ... e obter um hexdump de / dev / urandom com um número X de bytes, eles terão o mesmo valor exato (porque o tempo era o mesmo)?

    

Answer 1

Where does /dev/urandom gather these variables from.

Em todos os lugares, interrompa principalmente o tempo. Por exemplo, se você tiver uma placa de rede, o tempo exato que um pacote chegar será afetado pelo deslocamento entre a base de tempo de cristal na placa de rede e a base de tempo de cristal que faz o clock da CPU. O deslocamento entre dois osciladores de cristal de quartzo é afetado por variações microscópicas de temperatura da zona que se acredita serem realmente aleatórias fisicamente.

Se você tiver um disco giratório, o tempo de leitura será concluído depende da velocidade que o disco gira. Isso é afetado pela força de cisalhamento turbulenta entre a superfície do disco e o ar dentro do conjunto do disco. Enquanto isso não é acreditado para ser verdadeiro aleatoriedade física, é totalmente imprevisível ou repetível por qualquer mecanismo conhecido.

And if you have two machines set to the same time (down to the millisecond-if possible) and have the same speed, OS, etc...and take a hexdump of /dev/random with X number of bytes, will they have the same exact value (because the time was the same)?

Bem, milissegundos não seriam bons o suficiente. Você precisaria estar no mesmo nível em que a CPU mede o tempo - bilionésimos de segundo. Mas, claro, é assim que deve ser. Caso contrário, se você visse o estado de uma máquina, saberia com 100% de certeza que a outra máquina não poderia ter o mesmo estado. E como o estado deveria ser aleatório, você não deveria poder olhar para qualquer outra máquina e saber qualquer coisa sobre o estado com 100% de certeza. Contanto que as chances de isso ser conseguido sejam suficientemente baixas (digamos, menos de uma em 2 ^ 100), então está perfeitamente bem.

Mesmo que você jogue dois dados, cada um com um bilhão de lados, eles podem aparecer da mesma maneira. Desde que eles façam isso apenas uma vez a cada bilhões de vezes, então é como deveria ser.

    

Answer 2

Veja o manual de urandom , especificamente a descrição:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

Infelizmente eu não posso realmente responder sua segunda pergunta, eu estou usando outra pessoa pode, embora meu palpite seria que seria muito difícil obter exatamente o mesmo em ambas as máquinas.

    

Answer 3

In linux /dev/urandom is based of "environmental variables" and /dev/random is based off an algorithm and the time.

Ambas as suposições são falsas.

De acordo com aleatório (4) - página man do Linux ¹ , /dev/random reúne ruído ambiental de drivers de dispositivos e outras fontes em um pool de entropia .

Um exemplo de tal dispositivo é o mouse. ² Tente executar

head -c 1024 /dev/random | base64

para limpar o pool de entropia (abortar após alguns segundos) e, em seguida,

head -c 40 /dev/random | base64

para ler 40 bytes de /dev/random . Não faça nada e observe que head interrompe um tempo de log, já que não há nova entropia no conjunto.

Cancelar e depois executar

head -c 40 /dev/random | base64

novamente. Desta vez, passe o mouse rapidamente da esquerda para a direita. head terminará sua tarefa rapidamente.

Mais uma vez, de acordo com random (4) - página man do Linux , /dev/urandom usa o mesmo pool de entropia , mas não bloqueia. Se o pool de entropia não é grande o suficiente, ele cai para um gerador de números pseudo-aleatórios (PRNG) para criar mais (pseudo -) saída aleatória.

¹ O comportamento real pode variar de distro a distro.

² O exemplo se aplica ao Ubuntu 12.04. Outras distros podem ser diferentes.