/dev/random blocking is only useful during early boot and causes performance problems otherwise. A good seed should provide an “infinite” amount of entropy so blocking during system operation is obsolete. Applications that use the RNG after boot are recommended to use urandom because it doesn’t block. jitter-entropy ensures a well seeded boot environment and stops slow boot and blocking. Crypto like ECC uses entropy from the kernel and not via /dev/random. Jitter acts as a safety net for all crypto operations.
With the current config in Whonix / Kicksecure (haveged, jitterentropyrng user space daemon and kernel module), /dev/random has same performance as /dev/urandom?
yes
So in case of Whonix / Kicksecure we can use /dev/random all the way.
Yes we can. What custom software are you thinking of?
- swap-file-creator
- tirdad
- bootclockrandomization
- uwt time privacy
What facts are we endorsing if you remove it?
I think we should append what/why using it in Whonix the way we do, is better than a default distro?
I think it is important to keep the entire thought process documented for completion. This gives important context for the conclusion with both sides considered.
Makes sense.
Viewpoint: /dev/random is obsolete could be marked as obsolete and not kept as if this was still an equally valid position where nobody is really sure which one is right?
Let me know if it’s still contested but I guess Viewpoint: better use /dev/random is correct.
Viewpoint: better use /dev/random
I feel in that case it should be compressed into a footnote and cited as obsolete in the writeup " Viewpoint: better use /dev/random". This way it won’t be considered equal or cause confusion.
Re-reading the argument for /dev/random I feel it only helps in a very limited corner case - programs wanting entropy from an empty entropy pool. It does nothing to protect in case of the pool having a garbage or malicious seed.
For the former, GitHub - rfinnie/twuewand: A truerand algorithm for generating entropy would help. I can open a ticket if you decide to package it down the line so the topic doesn’t get buried.
Edit by Patrick:
2 posts were split to a new topic: twuewand - a truerand algorithm for generating entropy - Whonix integration
Fundamentally, developers shouldn’t be working with low level cryptographic APIs unless they are experts in cryptography. If you’re working with cryptography in your application, use libsodium.
Addressing the /dev/random cargo cult:
Use getrandom(). It’s the recommended way of obtaining random bytes and is used by Go’s crypto/rand, libsodium, hardened_malloc to seed its ChaCha8 CSPRNG, and others.
For older kernels, read a byte from /dev/random, then use /dev/urandom.
Linux 5.6 removed the blocking pool from /dev/random and made it functionally equivalent to getrandom(), but there’s no reason to use it when you can use getrandom().
/dev/random was based on the dated idea that entropy depleted. It isn’t true, and leads to developers devising weird workarounds to solve the problem.
You should remove the whole section that recommends the use of /dev/random for cryptographic use cases.
That section might need an update for Linux 5.6.
Please don’t delete it yet. Feel free to add a link or opinion there. I more time to research this.
swap-file-creator/usr/share/swap-file-creator/swap-file-creator at master · Kicksecure/swap-file-creator · GitHub reads from /dev/random but it’s written in bash so no libsodium.
Seems like this would have fit actually here better:
At first thought seems in a later kernel version getrandom() without GRND_INSECURE makes sense. Otherwise when it’s not possible to use getrandom() keep using /dev/random.
Quote Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND
Proponents of the viewpoint that “
/dev/randomis obsolete, use/dev/urandom, always” should explain:
- Why Linux offers both,
/dev/randomand/dev/urandomand why if it is “really the same” isn’t just a symlink from the one to the other.- Why Linux does not use the same code paths for
/dev/randomand/dev/urandom? Why have this distinction in the first place?
That’s an interesting link. I am going to read it. At first sight, seems it would be good to be added to the collection here:
Also generally that page could use improvements.
I am making this post to avoid over eagerly deletions of anything on that wiki page before I had a chance to catch up.
source: Improve entropy collection in VMs · Issue #673 · QubesOS/qubes-issues · GitHub
Stephan Mueller @smuellerDD is the author of jitterentropy-rng who also re-worked Linux kernel entropy said:
Yes, /dev/random or getrandom(2) blocks until it thinks it has sufficient entropy.
/dev/urandom should NOT be used for cryptographic purposes as it has no guarantee that sufficient seed is available.
author of:
https://www.chronox.de/lrng.html
Documentation and Analysis of the Linux Random Number Generator for the German government (BSI)
I asked:
Relevant quotes…
Would you like to have a look at Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND and like to comment?
More from Stephan Mueller @smuellerDD, source: Efficacy of jitterentropy RNG in Xen · Issue #6 · smuellerDD/jitterentropy-rngd · GitHub
Sure. The entire discussion around /dev/random vs /dev/urandom is quite
convoluted. Starting with 5.6 it should be simplified entirely:/dev/random (and getrandom(2) when invoked without flags) and /dev/urandom are
identical! The ONLY difference there is can be summarized:
/dev/random (and getrandom(2) without the flag to behave like /dev/urandom)
guarantees that at least 128 bits of entropy is available before it returns
data (based on the entropy heuristics the kernel applies)/dev/urandom always returns data irrespective whether sufficient seed is
returned.Beyond this, there is no difference.
IMHO there is one aspect missing in the kernel: /dev/random should return to
be blocked if it cannot be reseeded with sufficient seed at some time. I have
applied this in my LRNG /dev/random replacement.
The part IMHO there is one aspect missing in the kernel: /dev/random should return to be blocked if it cannot be reseeded with sufficient seed at some time. I have applied this in my LRNG /dev/random replacement. sounds like an awful security regression in linux kernel 5.6.