3 ms·

At which point? A quick skim of git log --after="2013" drivers/char/random.c to pick out a few that seem to just decide to change some part of the design. They

At which point? A quick skim of git log --after="2013" drivers/char/random.c to pick out a few that seem to just decide to change some part of the design. They might all be done for good reasons as I said it just seems to be pretty ad hoc. random: try to actively add entropy rather than passively wait for it random: only read from /dev/random after its pool has received 128 bits random: Return nbytes filled from hw RNG random: mix rdrand with entropy sent in from userspace random: use a different mixing algorithm for add_device_randomness() random: add backtracking protection to the CRNG random: replace non-blocking pool with a Chacha20-based CRNG random: use an improved fast_mix() function random: cap the rate which the /dev/urandom pool gets reseeded random: account for entropy loss due to overwrites random: allow fractional bits to be tracked And often very little justification or reasoning is recorded: random: replace non-blocking pool with a Chacha20-based CRNG The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. > I would be careful with the assumption that something like Fortuna is a "published and reviewed specification"; Fortuna is really just a case study Ferguson and Schneier wrote in _Practical Cryptography_. It's not a standard, or the winner of some kind of RNG design competition. Well that's basically what a standard is, in my mind. I place little weight on additional initials of organizations which publish standards, I just think they should be there so the design can be analyzed and examined as a whole, and by people who are not experts in C programming or want to wade through the Linux source. The section of the paper you linked would be a fine standard for Linux's RNG except that it's a continually moving target.

tptacek 5y ago
I think the ad hoc stuff you're talking about is mostly the kind of systems design detail you're going to get plugging any CSPRNG into a kernel. In particular: there's no way to get to a point where you can just reconcile a commit against a standard to know whether it's good or not; you're going to have to do the work of following and grokking the changelog no matter what, because no "standard" for a kernel CSPRNG is going to capture all the details of safely providing randomness to a Linux (or FreeBSD) kernel.
- throwawaylinux 5y ago
  It's not mostly that, there are many which change internal details of the algorithms (my post butchered the list of commits, I edited it and now they show up). And a complete design specification can certainly address the practical details of integration into a kernel, the random number subsystem in Linux has just a small interface with the rest of the kernel that can easily be captured abstractly.
  - tptacek 5y ago
    I don't know what I'm getting myself into rhetorically here. I'm not an apologist for the LRNG. My takes are just these: 1. It's not an unalloyed good thing to use "Fortuna", which is not so much a peer-reviewed standard as "a thing in a book with Bruce Schneier's name on it". I might be a little more nervous about a design that advertises being based on "Fortuna" than a random design, because the hard parts of doing a kernel CSPRNG are I think mostly not what they wrote about in that book. 2. Whether or not you have a reference design to base off of, you're still going to end up with a stream of fiddly commits determining i.e. when the generator is seeded well enough to release random bits to callers, or the order in which raw events are fed into the generator. Those annoying fiddly bits are the challenge of maintaining a secure RNG, and there's no standard anywhere that will release you from having to pay attention to that stuff (thankfully, Jason Donenfeld is doing that thankless work for us now). The rest of it, sure. The LRNG sucks, and is ill-specified (if relatively well studied), and has a janky history. It's in good hands now! It should not be rewritten to comply with some "standard"! But sure, the rest of your arguments, well taken, &c &c.

tptacek 5y ago

I think the ad hoc stuff you're talking about is mostly the kind of systems design detail you're going to get plugging any CSPRNG into a kernel. In particular: there's no way to get to a point where you can just reconcile a commit against a standard to know whether it's good or not; you're going to have to do the work of following and grokking the changelog no matter what, because no "standard" for a kernel CSPRNG is going to capture all the details of safely providing randomness to a Linux (or FreeBSD) kernel.

throwawaylinux 5y ago
It's not mostly that, there are many which change internal details of the algorithms (my post butchered the list of commits, I edited it and now they show up). And a complete design specification can certainly address the practical details of integration into a kernel, the random number subsystem in Linux has just a small interface with the rest of the kernel that can easily be captured abstractly.
- tptacek 5y ago
  I don't know what I'm getting myself into rhetorically here. I'm not an apologist for the LRNG. My takes are just these: 1. It's not an unalloyed good thing to use "Fortuna", which is not so much a peer-reviewed standard as "a thing in a book with Bruce Schneier's name on it". I might be a little more nervous about a design that advertises being based on "Fortuna" than a random design, because the hard parts of doing a kernel CSPRNG are I think mostly not what they wrote about in that book. 2. Whether or not you have a reference design to base off of, you're still going to end up with a stream of fiddly commits determining i.e. when the generator is seeded well enough to release random bits to callers, or the order in which raw events are fed into the generator. Those annoying fiddly bits are the challenge of maintaining a secure RNG, and there's no standard anywhere that will release you from having to pay attention to that stuff (thankfully, Jason Donenfeld is doing that thankless work for us now). The rest of it, sure. The LRNG sucks, and is ill-specified (if relatively well studied), and has a janky history. It's in good hands now! It should not be rewritten to comply with some "standard"! But sure, the rest of your arguments, well taken, &c &c.