Wgetting bytes from random.org

the sysadmin can add randomness, but the system will not trust that it is random (without
tweaking things via the ioctl), even if the sysadmin sends completely predictable data to
/dev/random it won't do any harm.

> My intuition was that /dev/random is (root) writable so that the sysadmin can incorporate
additional sources of entropy.

The distinction between mixing in new data into the random pool and adding to the entropy
estimate is what the article is about.

The in-kernel RNG maintains a pool of random data and an estimate of how much entropy is in
the pool.

When you read from /dev/(u)random, the entropy estimate is reduced.  When it reaches 0, reads
from /dev/random will block.  That's the easy part.

The difficult part is deciding when to increase the entropy estimate.  When you write 100
bytes to /dev/random, unless the 100 bytes are perfectly random, they should not add 800 bits
to the entropy estimate, but some lower value that only the person who generated the data is
able to choose reasonably.

For that reason, merely writing to /dev/random does not add to the entropy estimate; you need
to explicitly increase it by using the ioctl.

> So how is me writing bytes to /dev/random via a script any different than what my distro
(Slackware 12.0) does in rc.S (also a script) when the "carry-over" entropy file
(/etc/random-seed) is written to the random device?

It's no different.  Your distribution is mixing the old data into the random pool, but not
increasing the entropy estimate.  This way if the carry-over data is not truly random, no
serious security vulnerability will ensue.