6 ms·

random

21 points by tshtf 13y ago

aristidb 13y ago
Ouch. The assignee does not seem to care or understand why this this is a problem.
- pritambaral 13y ago
  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.
geocar 13y ago
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 13y ago
  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.
windexh8er 13y ago
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.
stcredzero 13y ago
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 13y ago
  > 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 13y ago
    > 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?
gwu78 13y ago
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.

21 points by tshtf 13y ago

aristidb 13y ago

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

pritambaral 13y ago
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.

geocar 13y ago

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 13y ago
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.

windexh8er 13y ago

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.

stcredzero 13y ago

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 13y ago
> 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 13y ago
  > 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?

gwu78 13y ago

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.