Por que escrever para / dev / random não torna a leitura paralela de / dev / random mais rápida?

Question

Geralmente, a leitura de /dev/random produz 100-500 bytes e blocos, aguardando a coleta de uma entropia.

Por que não gravar informações em /dev/random por outros processos acelera a leitura? Não deveria fornecer a entropia necessária?

Pode ser útil para desbloquear gpg ou software similar sem reiniciá-lo e reinserindo tudo, para gerar chaves não super-super-secretas, etc.

    

Answer 1

Você pode escrever para /dev/random porque é parte da maneira de fornecer bytes aleatórios extras para /dev/random , mas não é suficiente, você também precisa notificar o sistema de que há entropia adicional por meio de um ioctl() ligar.

Eu precisava da mesma funcionalidade para testar meu programa de configuração de smartcard , pois eu não queria Espero que meu mouse / teclado gere o suficiente para as várias chamadas para gpg que foram feitas para cada teste. O que fiz foi executar o programa Python, que segue, em paralelo aos meus testes. É claro que não deve ser usado para geração de chaves gpg real, já que a cadeia aleatória não é aleatória (informações aleatórias geradas pelo sistema ainda serão intercaladas). Se você tem uma fonte externa para definir a string para random , então você deve ter alta entropia. Você pode verificar a entropia com:

cat /proc/sys/kernel/random/entropy_avail

O programa:

#!/usr/bin/env python
# For testing purposes only 
# DO NOT USE THIS, THIS DOES NOT PROVIDE ENTROPY TO /dev/random, JUST BYTES

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
    time.sleep(0.001)

(Não se esqueça de matar o programa depois de terminar.)

    

Answer 2

Normalmente, ele é projetado por desenvolvedores de kernel e documentado em man 4 random :

Writing to /dev/random or /dev/urandom will update the entropy pool
with the data written, but this will not result in a higher entropy
count.  This means that it will impact the contents read from both
files, but it will not make reads from /dev/random faster.

    

Answer 3

Anthony já explicou que escrever para /dev/random não aumenta a contagem de entropia e mostrou como o ioctl RNDADDENTROPY (ver aleatório (4) ) pode ser usado para creditar a entropia. Obviamente, não é realmente seguro, então aqui está uma alternativa quando um gerador de números aleatórios de hardware estiver disponível.

As seguintes implementações tomam 512 bytes (4096 bits) de aleatoriedade de /dev/hwrng e encaminham para o pool de entropia (creditando 4 bits de entropia por byte, esta é uma escolha arbitrária minha). Depois disso, ele invocará o select (2) syscall para bloquear quando o pool de entropia for full (documentado no random (4) manpage).

Uma versão em Python:

import fcntl, select, struct
with open('/dev/hwrng', 'rb') as hw, open('/dev/random') as rnd:
    while True:
        d = hw.read(512)
        fcntl.ioctl(rnd, 0x40085203, struct.pack('ii', 4 * len(d), len(d)) + d)
        select.select([], [rnd], [])

Como o iso do Arch Linux não tem o Python instalado, aqui está uma versão do Perl também:

open my $hw, "</dev/hwrng" and open my $rnd, "</dev/random" or die;
for (;;) {
    my $l = read $hw, my $d, 512;
    ioctl $rnd, 0x40085203, pack("ii", 4 * $l, $l) . $d or die;
    vec(my $w, fileno $rnd, 1) = 1;
    select undef, $w, undef, undef
}

Isto é provavelmente o que o programa rngd (parte de rng-tools ) faz ( não verificado), exceto pelo fato de usar ferramentas (Python ou Perl) que já estão comumente disponíveis.