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

[DrYak]

I am not convinced that much in terms of entropy is needed for password generation.

The point of generating password is the password must be hard to predict.
A badly design password generator could have a big bias toward some feature (Ob. xkcd joke), vastly simplifying the brute forcing.

Although it's not a bug in a password generator, but in a random generator, a bug in Debian's number generator to only have 2^15 different starting positions, vastly simplifying any brute force attempts.

I think the "openssl" tool can generate keys for you.

True, there's that option too. Arch WIki suggests

dd if=/dev/random of=/keyfile_path

for key generation

[uid313]

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.

I think the "openssl" tool can generate keys for you.

[uid313]

Tools: yes, if specially if you pick some well established and well understood standard. Though that is more difficult in modern languages that lack an actual standard library. (don't just "git clone as a submodule" any random snippet of code you're found).

I am not convinced that much in terms of entropy is needed for password generation.

[DrYak]

With I/O testing you can use /dev/random, you don't need /dev/urandom for that,

You made a swap confusion:
/dev/random - is the blocking one that will wait until there's enough entropy
/dev/urandom - is the non-blocking that will always return, no matter the quality.

And with regards with IO testing...

also there are many dedicated I/O testing utilities.

...there are tools, yes. Because often you don't even need randomness in the cryptographic sense. Usually noise is good enough.
It might be a plain simple fast encryption stream with the seed used as a fixed password.
Or it might even be some mathematical pseaudorandom number generator.

For password generation there are tools for that, also it is easy to write one in Python (or some other language).

Tools: yes, if specially if you pick some well established and well understood standard. Though that is more difficult in modern languages that lack an actual standard library. (don't just "git clone as a submodule" any random snippet of code you're found).

"Easy to write": And equaly easy to screw up. My opinion is if you're not fluent in security matters, better not to roll your own. Colin Pierceval can very easily invent his own brand new password hasher. Aiden Junior straight out of Python Coding Bootcamp shouldn't touch security matters, unles everything is thoroughly reviewed and tested by a group of experts.

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.

[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).

[ix900]

This is just a random comment. hehehe.

[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.

[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).