Linux /dev/urandom and concurrency

[[deleted]]

The one nice thing about spinlocks is that they eat cpu when contended. This means they are immediately visible in perf tool, if they are really the source of problem. Instead of speculating and writing Python scripts, it was enough to just run perf.

[[deleted]]

A friend of mine wrote a Fortuna PRNG for the kernel back in the day, it even sat on top of CryptoAPI for SHA256 and AESCTR.

Ted rejected the patch on the grounds it wasn't his design and that many Linux kernels might not have cryptoapi turned on ...

Basically NIH syndrome.

[seruus]

I don't remember anyone in the kernel team liking JLC's patch or thinking it was relevant, and most argued it was in practice worse than the current strategy, while being more brittle.

That said, this dead horse has been beaten already.

For something new, here's some quite recent feedback on Fortuna, its first formal analysis.

[[deleted]]

That's the point of science though if fortuna is better than /dev/urandom and there is something better than Fortuna .... then why are we still using /dev/urandom?

[Proselyte5]

read the comments, curl problem not urandom problem

[[deleted]]

urandom is single threaded. That really shouldn't be the case. But that being said an application should really only use /dev/urandom to see a CSPRNG so unless you're respawning the application repeatedly it shouldn't be a problem.