What would be performance with proposed changes when running command below ? dd if=/dev/random iflag=fullblock of=file.bin bs=1024 count=1024 status=progress
No changes. Totally unrelated.
Uniting the Linux random-number devices
21–30 of 63 posts
Re: Uniting the Linux random-number devices
#22What would be performance with proposed changes when running command below ? dd if=/dev/random iflag=fullblock of=file.bin bs=1024 count=1024 status=progress
No changes. Totally unrelated.
I meant /dev/urandom, sorry.
Do you mean it is in reverse, in sense what getrandom() would be using ?
Re: Uniting the Linux random-number devices
#23As far as I can tell, there's little to nothing objectionable about this change; it makes urandom behave _more like_ random, by not yielding bytes before the kernel's entropy pool is in a good state (GRND_INSECURE). Systems where this would make urandom block for an objectionably long time (because CPU execution time jitter is unavailable or is believed to have low entropy) are largely hypothetical. I think you can s…
> I think you can still have specific reservations about CPU execution time jitter, though my experience [...]
Just want to point out that the Linus Jitter Dance is already in use today. It's been there for three years. I had nothing to do with that change. The change that I'm now proposing, which this article is about, changes nothing about the Linus Jitter Dance. Whether you like it or not, it's being used already, and has been for three years now, affecting all interfaces to the rng.
I only mention it in my patch, for the sole purpose of indicating that blocking in /dev/urandom has been unproblematic for three years now, because it will unblock a second later. That's the only at all reason why I mention the Linus Jitter Dance.
The only purpose of the patch is to make /dev/urandom block.
> I also think you can still have specific reservations about how the kernel 'shepherds' its pool of random bits. [...] It would seem best if the kernel used a cryptographic algorithm
Actually, it will do this for 5.18, authored a few weeks ago: https://git.kernel.org/pub/scm/linux/kernel/git/crng/random....
Re: Uniting the Linux random-number devices
#24Earlier quoted context omitted.
E.g. Linux can't assume that the system has a writable disk.
Nor can OpenBSD. The system doesn't crash if /etc/random.seed isn't writable.
But what if it wasn't writeable recently but has been in the past? How do you know that the seed data isn't stale and you are starting up the entropy pool in exactly the same state as last time, and the time before that, and ...
In some security contexts this could be a significant concern.
Re: Uniting the Linux random-number devices
#25Earlier quoted context omitted.
How did they solve it?
The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block. Add.: the seed file is unique per installation, and is also updated continously by the system.
Linux keeps track of "credit" for entrophy pool sources.
Anyone can write to /dev/random - this mixes data into the entrophy pool but it won't be "credited" as securely increasing /proc/sys/kernel/random/entropy_avail . https://www.whonix.org/wiki/Dev/Entropy
Similarly, systemd-boot can seed from disk but will not "credit" entrophy. https://systemd.io/RANDOM_SEEDS/
If the point of /dev/random is to provide crytographically secure random numbers, then some level of paranoia is needed for determining which sources are "credited" for initializing the pool. https://lwn.net/Articles/760121/
Re: Uniting the Linux random-number devices
#26Can Linux use Hardware RNG devices? Are these devices able to generate enough bits of randomness to work for boot?
Yes. This happens via random.c's add_hwgenerator_randomness() hook, which the hwrng framework calls from a kthread.
Re: Uniting the Linux random-number devices
#27I just sent a v1 of this patch: https://lore.kernel.org/lkml/20220217162848.303601-1-Jason@z... We'll see if that elicits any real objections. Hopefully not, and this will be part of 5.18!
Seems like a no-brainer to me; as I understand, this effectively make urandom “always secure”, which is a very good thing; makes for an even more convincing argument when some colleague insists on using /dev/random “because it’s more secure”.
Do I understand correctly that with this patch, the only drawback is for weird architectures that do not have an instruction counter or another instruction to gather random data? And in those cases, the old behavior (“urandom may be insecure shortly after boot”) may even be worse than the new behavior (“may block while waiting for entropy”) ?
Re: Uniting the Linux random-number devices
#28Earlier quoted context omitted.
How did they solve it?
The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block. Add.: the seed file is unique per installation, and is also updated continously by the system.
Seed files are useful, but not a perfect solution, because they can be snapshotted or cloned in a virtual machine context, or otherwise shared/leaked. Also, they require a device to have writeable memory, which again does not work in all contexts.
I don't think trying to spin this as "OpenBSD solved this years ago" is especially helpful. OpenBSD has made a different set of design tradeoffs than the Linux authors, and both are arguably reasonable designs.
Re: Uniting the Linux random-number devices
#29Earlier quoted context omitted.
E.g. Linux can't assume that the system has a writable disk.
Nor can OpenBSD. The system doesn't crash if /etc/random.seed isn't writable.
OpenBSD's non-blocking design, as you've described it, isn't secure if that file isn't writeable. The security of the design assumes that file is writeable. It may not crash, but instead it "fails open."
Re: Uniting the Linux random-number devices
#30Earlier quoted context omitted.
The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block. Add.: the seed file is unique per installation, and is also updated continously by the system.
Linux keeps track of "credit" for entrophy pool sources. Anyone can write to /dev/random - this mixes data into the entrophy pool but it won't be "credited" as securely increasing /proc/sys/kernel/random/entropy_avail . https://www.whonix.org/wiki/Dev/Entropy Similarly, systemd-boot can seed from disk but will not "credit" entrophy. https://systemd.io/RANDOM_SEEDS/ If the point of /dev/random is to provide crytograph…
On OpenBSD only root can write to urandom, but anyone can provide entropy through for example disk i/o and keyboard input. I might be wrong, but I suspect the rationale is that if someone has root access to your system, you have plenty more to worry about besides the entropy pool.