51–60 of 67 posts
Earlier quoted context omitted.
I don't understand why it's not possible to make /dev/random block until there is enough entropy in the pool for the seed, and never block afterwards when it can securely do key-stretching. After seeding, there is no point in blocking on a lack of entropy, which is why it is recommended to use /dev/urandom in the first place.
This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described. S…
E.g., if on a platform with a hardware RNG then it should never be necessary to block: just read 128 bits out of the hardware RNG & generate a stream of random numbers.
On a platform without a hardware RNG, could one require a previous seed? An installer could install the seed in some persistent storage somewhere, so there's no need to do this even on boot. A VM system needs someway to atomically read the seed & then write a new seed.
On a platform without a hardware RNG and without a previous seed (i.e., the very first boot after a hand-install or something), could the system require the user to type keys until it has collected 128 bits of entropy?
I'm not certain if there's a good answer on systems with no hardware RNG, no previous seed and no input capability. Maybe CPU timing loops or somesuch?
It'd be also be nice were there a filesystem interface to getrandom(2) …
Earlier quoted context omitted.
There's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.
If you have network access early enough in the install and/or boot processes could you not pluck some random bits from a web service to pump more entropy into the RNG's pool? For paranoia you could host your own fairly easily instead of using a public one: have a machine that is publicly visible respond with random digits from its own entropy pool, have it use one or more of various methods to keep that pool topped u…
Earlier quoted context omitted.
This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described. S…
Is there a way to review the different paths and come up with answers for all of them? E.g., if on a platform with a hardware RNG then it should never be necessary to block: just read 128 bits out of the hardware RNG & generate a stream of random numbers. On a platform without a hardware RNG, could one require a previous seed? An installer could install the seed in some persistent storage somewhere, so there's no nee…
Typically, the crypto is needed for network communication. It can provide some randomness too...
Also I think it's common knowledge that there's little entropy available during startup but developers have no control over it regardless.
I didn't know it was that bad though. That's really bad.
Seeing that `i % len` in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... makes me uncomfortable. This is performing a non-constant modulus on every loop iteration, which seems quite excessive even for a slow path. Performing wraparounds using a separate branch would be more efficient.
Additionally, CHACHA20_KEY_SIZE is a power of 2 and optimizing compilers like GCC will convert the modulus into a binary-AND.
Earlier quoted context omitted.
From TFA: > == Discarded early randomness, including device randomness == > == RNG is treated as cryptographically safe too early == > == Interaction between kernel and entropy-persisting userspace is broken == > == No entropy is fed into NUMA CRNGs between rand_initialize() initcall and crng_init==2 == > == initcall can propagate entropy into primary and NUMA CRNGs while crng_init==1 == and > == Impact == > I have s…
"105 bits" isn't too shabby. I'd only start to worry when it gets to say 70 bits or less. That's the kind of size a state actor could precompute ssh host keys for each of the initial random number states in a common distro for example. If a state actor could compute ssh keys in 50 milliseconds on custom hardware, and they had 100,000 machines generating those keys, they could generate enough keys to have a 1 in 1 mil…
Earlier quoted context omitted.
It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.
> It's better to deadlock than to revert to a weak RNG ..for you. Other people have a different threat model where availability is ranked above RNG strength in the first minute of booting. Making security decisions not based on any sort of threat model considerations is zealotry/cargo-culting, IMO.
Earlier quoted context omitted.
Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted. The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.
It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.
Above all else, the rule is that the kernel shouldn't cause userspace regressions. Something that works now must continue working later.
Earlier quoted context omitted.
There's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.
You may know this but for others who may not: there are tools like virt-sysprep that can (among other things) inject a random seed into disk images. If you clone/generate VMs from one "master" image, running virt-sysprep (or similar) is one of the steps you should do right before launching a new instance (inject a new random seed, wipe out any SSH host keys, etc.) Even DigitalOcean missed doing this step a while back…