Why writing to /dev/random does not make parallel reading from /dev/random faster?

Question

Typically reading from /dev/random produces 100-500 bytes and blocks, waiting for an entropy to be collected.

Why doesn't writing information to /dev/random by other processes speed up reading? Shouldn't it provide the required entropy?

It can be useful for unblocking gpg or similar software without restarting it and re-entering everything, for generating non-super-top-secret keys, etc.

Answer 1

You can write to /dev/random because it is part of the way to provide extra random bytes to /dev/random, but it is not sufficient, you also have to notify the system that there is additional entropy via an ioctl() call.

I needed the same functionality for testing my smartcard setup program, as I did not want to wait for my mouse/keyboard to generate enough for the several calls to gpg that were made for each test run. What I did is to run the Python program, which follows, in parallel to my tests. It of course should not be used at all for real gpg key generation, as the random string is not random at all (system generated random info will still be interleaved). If you have an external source to set the string for random, then you should be able to have high entropy. You can check the entropy with:

cat /proc/sys/kernel/random/entropy_avail

The program:

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

(Don't forget to kill the program after you are done.)

Answer 2

Typically, it's designed by kernel developers and documented 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.

Answer 3

Anthony already explained that writing to /dev/random does not increase the entropy count and showed how the RNDADDENTROPY ioctl (see random(4)) can be used to credit for entropy. It is obviously not really secure, so here is an alternative when a hardware random number generator is available.

The following implementations take 512 bytes (4096 bits) of randomness from /dev/hwrng and forward it to the entropy pool (crediting 4 bits of entropy per byte, this is an arbitrary choice from me). After that it will invoke the select(2) syscall to block when the entropy pool is full (documented in the random(4) manpage).

A Python version:

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], [])

Since the Arch Linux iso did not have Python installed, here is a Perl version too:

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
}

This is probably what the rngd program (part of rng-tools) does (unverified), except that it uses tools (Python or Perl) that are already commonly available.