Perché scrivere su /dev/random non rende più veloce la lettura parallela da /dev/random?

Puoi scrivere a /dev/random perché fa parte del modo per fornire byte casuali extra a /dev/random , ma non è sufficiente, devi anche notificare al sistema che c'è ulteriore entropia tramite un ioctl() chiamata.

Avevo bisogno della stessa funzionalità per testare il mio programma di configurazione della smartcard, poiché non volevo aspettare che il mio mouse/tastiera generasse abbastanza per le numerose chiamate a gpg che sono stati fatti per ogni esecuzione di prova. Quello che ho fatto è eseguire il programma Python, che segue, in parallelo ai miei test. Ovviamente non dovrebbe essere usato per il vero gpg generazione di chiavi, poiché la stringa casuale non è affatto casuale (le informazioni casuali generate dal sistema saranno comunque interlacciate). Se hai una fonte esterna per impostare la stringa per random , allora dovresti essere in grado di avere un'alta entropia. Puoi controllare l'entropia con:

cat /proc/sys/kernel/random/entropy_avail

Il programma:

#!/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)

(Non dimenticare di chiudere il programma dopo aver finito.)

In genere, è progettato dagli sviluppatori del kernel e documentato in 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.