|
|
Subscribe / Log in / New account

The search for truly random numbers in the kernel

The search for truly random numbers in the kernel

Posted Sep 20, 2013 19:10 UTC (Fri) by gmaxwell (guest, #30048)
In reply to: The search for truly random numbers in the kernel by ikm
Parent article: The search for truly random numbers in the kernel

::facepalm::

The entropy estimator is a counter. It is incremented by a scarce few entropy sources in the kernel. Decremented on read from /dev/random. When it reaches zero /dev/random blocks. I am talking about the housekeeping, not quality of the CSPRNG.

On a busy system (e.g. one with a lot of SSL activity) it is very easy to get mysteriously poor performance— things like SSH taking a long time to connect, as various random tasks block trying to read a few bytes from /dev/random.

Here is a monitoring on a system which has this problem (but normally has a daemon running that keeps the pool full, you can see what happens when the daemon is down): http://mf4.xiph.org/munin/xiph.org/mf4.xiph.org/entropy-y... (the graph claims 'bytes' but its really bits, and when its at zero, ssh connections and such start becoming visibly slow)


to post comments

The search for truly random numbers in the kernel

Posted Sep 20, 2013 19:32 UTC (Fri) by ikm (guest, #493) [Link] (1 responses)

Oh, I see what you meant now. But do SSH/SSL sessions really use /dev/random and not /dev/urandom? Sounds like an overkill to me. Once /dev/urandom is properly seeded, I would expect the numbers it provided to be sufficiently random for session keys.

The search for truly random numbers in the kernel

Posted Sep 20, 2013 20:00 UTC (Fri) by gmaxwell (guest, #30048) [Link]

SSH does, at least on some systems. If this is advisable or not is another question.

When long-term secrets are used for signing with DSA then whatever argument for /dev/random there was in the first place also really applies to the nonce generation— since weak nonces will leak the private key.

To some extent there is pressure on developers to use the "more secure" thing so long as it exists. No one wants to be wearing the dunce cap for some massive security compromise.

But it would be nice if there were enough space in the pool that it wasn't quite so much of a trap.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds