Pourquoi écrire dans /dev/random ne rend pas la lecture parallèle depuis /dev/random plus rapide ?

Vous pouvez écrire à /dev/random car cela fait partie du moyen de fournir des octets aléatoires supplémentaires à /dev/random , mais ce n'est pas suffisant, il faut aussi notifier au système qu'il y a de l'entropie supplémentaire via un ioctl() appel.

J'avais besoin de la même fonctionnalité pour tester mon programme d'installation de carte à puce, car je ne voulais pas attendre que ma souris/clavier génère suffisamment pour les plusieurs appels à gpg qui ont été faites pour chaque essai. Ce que j'ai fait, c'est exécuter le programme Python, qui suit, en parallèle de mes tests. Cela ne devrait bien sûr pas être utilisé du tout pour de vrais gpg génération de clé, car la chaîne aléatoire n'est pas du tout aléatoire (les informations aléatoires générées par le système seront toujours entrelacées). Si vous avez une source externe pour définir la chaîne pour random , alors vous devriez pouvoir avoir une entropie élevée. Vous pouvez vérifier l'entropie avec :

cat /proc/sys/kernel/random/entropy_avail

Le programme :

#!/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'oubliez pas de tuer le programme une fois que vous avez terminé.)

Généralement, il est conçu par les développeurs du noyau et documenté dans 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.