

Default configuration of rng-tools in Arch adds no real entropy to /dev/random - tshtf
https://bugs.archlinux.org/task/34580?string=rng-tools&project=1&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

======
windexh8er
Really - front page? Read the comments. The bug was filed based on a packaged
image for EC2. As stated there: rng-tools is not a required package for Arch.

edit: I understand the concern of RNGD_OPTS, but still think that if you're
installing rng-tools you should likely know what you're doing with it. As
stated by rng-tools:

"... Using the standard open()and read() system calls, you can read random
data from the hardware RNG device. This data is NOT CHECKED by any fitness
tests, and could potentially be bogus (if the hardware is faulty or has been
tampered with). Data is only output if the hardware "has-data" flag is set,
but nevertheless a security-conscious person would run fitness tests on the
data before assuming it is truly random."

...so, in all reality the flag should be unset forcing the user to select a
hardware, or other RNG device. /dev/random is likely a very bad idea as a
default.

So is any simplified facility that caches data from places like random.org and
provides it as a continuous stream of large pools of entropy? It'd be nice if
a data source such as that could be used as a simplistic way to bootstrap the
entropy pool on a new system.

------
gwu78
mtorromeo's analogy is flawed.

With sshd, the user has to enable it (change startup settings or launch it
manually) to become "less secure". By contrast, with rng-tools, she must
change settings to become _more secure_.

Ever heard of the term "sane defaults"? To me, sane defaults are ones that by
default, out of the box, keep the user secure. Decreasing the user's security,
maybe to achieve increased functionality or ease of use, should require action
on the part of the user. Why? Because history tells us that most users are
lazy and will take little or no action. That includes action necessary to be
secure.

------
aristidb
Ouch. The assignee does not seem to care or understand why this this is a
problem.

~~~
pritambaral
Please read all the comments. The assignee has clearly stated:

>> Other than that, I am not strongly against changing the default
configuration of rngd but I don't see the point and on the majority of systems
there is no hardware entropy generation module, so at least this configuration
always works.

>> This package is not a dependency of any other package. It also needs to be
explicitly installed AND started/enabled so after installation the system is
not any less secure.

------
stcredzero
Are there online services that provide hardware based entropy? Found one:
[http://openfortress.org/cryptodoc/random/](http://openfortress.org/cryptodoc/random/)

The problem here is that to securely use entropy, an encrypted channel is
needed, but it's hard to establish one without a source of entropy.

Mobile and personal computing devices need to have hardware entropy. It should
be required.

~~~
zokier
> Mobile and personal computing devices need to have hardware entropy. It
> should be required.

I guess it's a good thing then that Intel added RdRand on IvyBridge. And
doesn't TPM also have hardware RNG in it?

~~~
stcredzero
> I guess it's a good thing then that Intel added RdRand on IvyBridge. And
> doesn't TPM also have hardware RNG in it?

Sarcasm detected. Intentional or no?

------
geocar
This is difficult to process.

Does rng-tools effectively do this?

    
    
        dd if=/dev/urandom of=/dev/urandom bs=512 count=1
    

Or is someone doing the (more) sensible thing of saving the random state at
shutdown and reloading it at startup?

~~~
aristidb
rng-tools is supposed to feed entropy from a hardware random number generator
into /dev/random, but feeding it /dev/urandom instead adds fake entropy.

