1
3
Conversation
Yes? Those slides also state, that the linux kernel uses disk and input device events to gather entropy for its random pool.
1
What I mean is that dont implement your own CSPRNG. Just use system wide available option. It's 21st century and OSX/Linux/Windows all have secure-rng's API's, that are much better than what you can built.
1
I am aware of that. But the OT was, that the whole "move your mouse" thing is not necessary anymore (if I understood corerctly), which I am disputing.
1
Current pools of entropy are collecting, mouse, keystrokes, operations timeouts, and recycles using CHACHA20. By the time you started your computer, you already did mouse moves, keyboard strokes, etc. So unless they have their own PRNG that uses them, there is no reason for msg.
1
The kernel is capturing them and is using them to increase the entropy available.
The message might not be extremely important, but it is not wrong.
2
1
Entropy isn't depleted by having a CSPRNG generate random data. Using the nonsensical Linux /dev/random API instead of getrandom() is a bug. Other operating systems like OpenBSD don't provide a faulty /dev/random implementation at all. It really shouldn't be used on Linux at all.
1
1
Linux /dev/urandom is faulty and returns data before being initialized. Linux /dev/random API is faulty and uses a nonsensical cargo cult design blocking after initialization without providing meaningful security properties from it. Software not using getrandom() is just broken.
1
I am sorry, but what you've just said is utterly false. getrandom just proxy for urandom/random.
Additionally the only worry with URANDOM if you have never started the machine. OSs are saving the seed between the cycles, so that there is always propagation of entropy.
1
It's completely accurate and you're just misinterpreting what I said and making a strawman argument. I never said it used a different pool than urandom but rather than the API is sane since it won't ever return data when uninitialized. I clearly explained it in the other thread.
1
The /dev/random API is a nonsense concept not based on any real threat model, security rationale or cryptographic basis. It doesn't actually provide a property like better backwards secrecy. It doesn't make sense to use it either via the legacy file API or the getrandom flag.
The rationale for programs using /dev/random has always been that /dev/urandom could be uninitialized, and the getrandom API eliminates that rationale by fixing the problem. Saving / restoring entropy between boot is useful and is done by Android and systemd but that isn't a fix.
1
The first boot matters, and there isn't necessarily enough entropy generated even for use during the subsequent boots. Many of the real world issues caused by low entropy keys occurred on embedded devices during the initial boot. They generate keys on first boot to start working.
1
Show replies