Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
1  
Just read from /dev/urandom instead. /dev/urandom is as secure as /dev/random for cryptographic use, the behavior of /dev/random is bad design. –  Gilles Jul 7 at 22:23
    
How to switch gpg --gen-key from /dev/random to /dev/urandom without restarting? –  Vi. Jul 7 at 22:33
    
IIRC gpg has /dev/random hard-coded. You can change your udev configuration to make /dev/random the same device as /dev/urandom, among other possibilities. –  Gilles Jul 7 at 22:39
    
@Gilles, it still requires restarting gpg --gen-key, therefore re-endering data it interactively asks (or using more clever methods like specifying more command line parameters). Also CPU time generating the prime whould be lost (gpg can work a minute, print some +es and then request additional random data). And it gives "let's go back and go other route" feeling instead of "let's take a hammer and force it forward"... –  Vi. Jul 7 at 22:41

2 Answers 2

up vote 17 down vote accepted

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.)

share|improve this answer
    
Much simpler solution would be to use rngd. It's available as a package in most (all?) distros. –  Patrick Jul 7 at 21:07
3  
random = "3420348024823049823-984230942049832423l4j2l42j" see xkcd.com/221 –  immibis Jul 8 at 0:21
    
@Patrick I tried at least 3 potential solutions for adding randomness, IIRC rngd was one of them. But they would not work out of the box (it could be the Ubuntu 12.04 setup at the time), and for me this solution, with 10 lines of code, was simpler. –  Anthon Jul 8 at 2:22
    
@Anthon: as a sidenote, I haven't seem xs4all.nl since mitnik used it to store some things, decades ago... :) –  woliveirajr Jul 8 at 16:26
    
@woliveirajr, I had my account from hacktic.nl transferred there somewhere in 1992, I have been there a while although I haven't lived in the Netherlands for over 20 years now. –  Anthon Jul 8 at 16:40

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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.