/dev/random Is More Like /dev/urandom With Linux 5.6

[phoronix]

Phoronix: /dev/random Is More Like /dev/urandom With Linux 5.6

The random changes have been sent in for Linux 5.6 that yield /dev/random behavioral changes and a new random flag...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework

[archkde]

Finally. This was long due.

[elatllat]

So using urandom where possible and installing rng-tools or haveged for anything else is still required.

[uid313]

So using urandom where possible and installing rng-tools or haveged for anything else is still required.

Well you never really use /dev/urandom yourself.
You usually use a programming language then get the random data from whatever functionality is provided by the language, such as in Python by importing the "random" module, or in PHP with the rand() function.

[elatllat]

Well you never really use /dev/urandom yourself.
You usually use a programming language then get the random data from whatever functionality is provided by the language, such as in Python by importing the "random" module, or in PHP with the rand() function.

To avoid depleting my entropy pools with TLS I need to tell java to use urandom (it's a config setting).
I use urandom directly from bash scripts for password generation and IO testing.

[uid313]

To avoid depleting my entropy pools with TLS I need to tell java to use urandom (it's a config setting).
I use urandom directly from bash scripts for password generation and IO testing.

Oh, I didn't know you needed to tell Java where to get it entropy from.
With I/O testing you can use /dev/random, you don't need /dev/urandom for that, also there are many dedicated I/O testing utilities.
For password generation there are tools for that, also it is easy to write one in Python (or some other language).

[elatllat]

Oh, I didn't know you needed to tell Java where to get it entropy from.
With I/O testing you can use /dev/random, you don't need /dev/urandom for that, also there are many dedicated I/O testing utilities.
For password generation there are tools for that, also it is easy to write one in Python (or some other language).

The option to select default random source in Java is way better than improper use of python, etc where one would have to edit open source, dependency manage and compile just to change os.[u]random().

For IO testing If you don't want to impact a running system, or wait a long time, it's best to avoid /dev/random, sure there are many tools but sometimes the simple ones are the best for many reasons.

For bulk password generation, again if one does not want to adversely impact the systems by depleting the entropy pool it's best to ensure urandom is used regardless of language.

Granted entropy pool depletion is mostly a server issue but, just saying it can make for a bad day if one uses the wrong tool without understanding its internals.

[ix900]

This is just a random comment. hehehe.

[xinorom]

Well you never really use /dev/urandom yourself.
You usually use a programming language then get the random data from whatever functionality is provided by the language, such as in Python by importing the "random" module, or in PHP with the rand() function.

You never blindly substitute between those two things unless you're completely and utterly braindead though. The random number generators in most languages use their own PRNG or call some function from libc, which in many cases don't use /dev/urandom at all (or anything approaching the same level of quality).

[Guest]

Well you never really use /dev/urandom yourself.
You usually use a programming language then get the random data from whatever functionality is provided by the language, such as in Python by importing the "random" module, or in PHP with the rand() function.

Except when generating keys for encrypted partitions, SSL etc. In that case you'll need to use /dev/random or /dev/urandom directly in a shell command.