4 ms·

Using /dev/urandom as password source is a very bad idea.

by jojo1 16y ago

asymptotic 16y ago
Agreed. /dev/urandom should be mixed with other sources of entropy (system statistics, epoch, low-level counters, cryptographic PRNGs like Yarrow) and then "combined" using a cryptographic hash. Such a principle is used in e.g. Fortuna. See: https://secure.wikimedia.org/wikipedia/en/wiki/Fortuna_%28PRNG%29 https://secure.wikimedia.org/wikipedia/en/wiki/Fortuna_%28PR...
- jojo1 16y ago
  Or just use /dev/random :)
  - getsat 16y ago
    Reads from /dev/random will block when the entropy pool is empty. You can see the number of bits of entropy available on a Linux systems via: $ cat /proc/sys/kernel/random/entropy_avail If you need more, better randomness, check out the Entropy Key: http://www.entropykey.co.uk/ http://www.entropykey.co.uk/
    - chalst 15y ago
      Blocking /dev/random when entropy is low is the correct behaviour, but it is a system-dependent behaviour. Darwin (Mac OSX) has the two sources behave identically. The Darwin man page justifies this behaviour saying: /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected. With Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either. and then contradicts itself later by saying: Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The quality of its output is however dependent on regular addition of appropriate entropy.
- deleted 16y ago
  [deleted]
- dchest 16y ago
  /dev/urandom should be mixed with other sources of entropy (system statistics, epoch, low-level counters, cryptographic PRNGs like Yarrow) It's already cryptographically secure PRNG, and already mixes sources that you mentioned, same as /dev/random (except on Linux /dev/random blocks when there's not enough entropy, and urandom doesn't).
y0ghur7_xxx 16y ago
Care to explain why?
- thamer 16y ago
  A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys. http://en.wikipedia.org/wiki//dev/random http://en.wikipedia.org/wiki//dev/random
- asharp 16y ago
  On virtual machines, /dev/urandom contains very little if any entropy. Basically /dev/random takes entropy from the system and feeds it to you. /dev/urandom is a psudorandom number generator that reseeds from entropy as it gets it. Ie. if it has no entropy, your random numbers are anything but random.
  - tptacek 16y ago
    This is a drastic oversimplification. Both urandom and random (on Linux; there's no difference between the two on BSD) are seeded from hard entropy sources. Both urandom and random extract entropy by updating pools with SHA1. The difference is that random has an estimator and will demand more hard entropy when it has serviced too many requests. But it's not as if urandom goes from producing "101010100101000101010100111001" to "111011011110111101111111110111" when entropy is depleted. In any case, this is entirely irrelevant to the discussion at hand. You can absolutely use /dev/urandom to make a one-shot crypto key. You shouldn't wire /dev/urandom up into an online cryptosystem (don't use it to produce DH parameters, for instance), but even then, urandom isn't going to be how your system really gets broken. In your case, experimenting with encrypting whole files with RSA instead of using RSA to exchange keys is what's really going to break your system. This is almost a decent example of how people obsess over the wrong things in cryptosystem design, and why perhaps generalist programmers should stay far, far away from this stuff.
tptacek 16y ago
Using /dev/urandom as a password source is fine. It's a CSPRNG. It theoretically degrades if you exhaust entropy, but there's no current attack I know of based on that property. Also, RNG attacks are usually "online", meaning an attacker gets to continually interact with the RNG. This is a one-off offline use. In this scenario, you could probably survive with rand().

Using /dev/urandom as password source is a very bad idea.

by jojo1 16y ago

Using /dev/urandom as password source is a very bad idea.

Agreed. /dev/urandom should be mixed with other sources of entropy (system statistics, epoch, low-level counters, cryptographic PRNGs like Yarrow) and then "combined" using a cryptographic hash. Such a principle is used in e.g. Fortuna. See: https://secure.wikimedia.org/wikipedia/en/wiki/Fortuna_%28PRNG%29 https://secure.wikimedia.org/wikipedia/en/wiki/Fortuna_%28PR...

jojo1 16y ago
Or just use /dev/random :)
- getsat 16y ago
  Reads from /dev/random will block when the entropy pool is empty. You can see the number of bits of entropy available on a Linux systems via: $ cat /proc/sys/kernel/random/entropy_avail If you need more, better randomness, check out the Entropy Key: http://www.entropykey.co.uk/ http://www.entropykey.co.uk/
  - chalst 15y ago
    Blocking /dev/random when entropy is low is the correct behaviour, but it is a system-dependent behaviour. Darwin (Mac OSX) has the two sources behave identically. The Darwin man page justifies this behaviour saying: /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected. With Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either. and then contradicts itself later by saying: Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The quality of its output is however dependent on regular addition of appropriate entropy.
deleted 16y ago
[deleted]
dchest 16y ago
/dev/urandom should be mixed with other sources of entropy (system statistics, epoch, low-level counters, cryptographic PRNGs like Yarrow) It's already cryptographically secure PRNG, and already mixes sources that you mentioned, same as /dev/random (except on Linux /dev/random blocks when there's not enough entropy, and urandom doesn't).

y0ghur7_xxx 16y ago

Care to explain why?

thamer 16y ago
A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys. http://en.wikipedia.org/wiki//dev/random http://en.wikipedia.org/wiki//dev/random
asharp 16y ago
On virtual machines, /dev/urandom contains very little if any entropy. Basically /dev/random takes entropy from the system and feeds it to you. /dev/urandom is a psudorandom number generator that reseeds from entropy as it gets it. Ie. if it has no entropy, your random numbers are anything but random.
- tptacek 16y ago
  This is a drastic oversimplification. Both urandom and random (on Linux; there's no difference between the two on BSD) are seeded from hard entropy sources. Both urandom and random extract entropy by updating pools with SHA1. The difference is that random has an estimator and will demand more hard entropy when it has serviced too many requests. But it's not as if urandom goes from producing "101010100101000101010100111001" to "111011011110111101111111110111" when entropy is depleted. In any case, this is entirely irrelevant to the discussion at hand. You can absolutely use /dev/urandom to make a one-shot crypto key. You shouldn't wire /dev/urandom up into an online cryptosystem (don't use it to produce DH parameters, for instance), but even then, urandom isn't going to be how your system really gets broken. In your case, experimenting with encrypting whole files with RSA instead of using RSA to exchange keys is what's really going to break your system. This is almost a decent example of how people obsess over the wrong things in cryptosystem design, and why perhaps generalist programmers should stay far, far away from this stuff.

tptacek 16y ago

Using /dev/urandom as a password source is fine. It's a CSPRNG. It theoretically degrades if you exhaust entropy, but there's no current attack I know of based on that property. Also, RNG attacks are usually "online", meaning an attacker gets to continually interact with the RNG. This is a one-off offline use. In this scenario, you could probably survive with rand().