<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <div class="moz-cite-prefix">On 3/6/26 8:16 AM, Patrick Chkoreff

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:2f1d20ad-d180-4098-8ec3-5834b97158a8@fexl.com">In other

      words, I would just rely entirely on Theodore Tso's code.  Go

      Ted. <br>

    </blockquote>

    <p>I like Ted's code, but if you want to Xor in additional

      (uncorrelated!) data, go ahead. It can't hurt. Linux /dev/urandom

      is great but the idea that RNG is solved, so simplify, and don't

      look for additional entropy always worries me.</p>

    <p>Ted's code is quite happy to have you feed in additional entropy

      sources. Write new data into /dev/urandom.</p>

    <p>I once architected a "casino grade" RNG that I think I got

      approved in a couple jurisdictions (there were only three at that

      point: NV, NY, and Indian casinos). It was just a packaging of a

      fairly early version of Ted's Linux code, Though those were dark

      days when someone else was maintaining the driver and he was on an

      idiot mission, busily removing every entropy source he could

      because if the source couldn't be quantified it had to go,

      starving the kernel of entropy. A misguided idea, one that might

      be characterized as removing "squish", I think could be the word.

      I followed him around (in our copy of the kernel) turning back <i>on</i>

      every source I could find. I also searched our hardware looking

      for every other source of both entropy and uniqueness I could find

      (unique machine readable serial numbers and old fashioned

      hard-coded MAC addresses, etc). This was a long time ago, at that

      point the power-on value of DRAM didn't come up zeros but had crap

      in it that wasn't quite the same every time. We had 1GB of RAM, I

      wrote that into /dev/urandom at every boot. There was a fan from

      which I could read speed, there was a voltage or two I could read,

      I think I tracked down a temperature or two. I also devised a

      manufacturing procedure that uniquely initialized each unit's

      stored entropy pool on disk. I also set up a cron job to regularly

      store the pool so on a machine that wasn't designed to be politely

      powered down the stored value read at boot would be different at

      every boot.</p>

    <p>My approach was to trust a quality RNG, but feed it well.</p>

    <p>These days I would take a similar approach, but I would be well

      reassured that at current system clock rates, time stamping when

      interrupts get serviced is a great source of entropy, no matter

      the interrupt source. Maybe not a good source of "theoretical"

      entropy but still nice squishy entropy in the sense that anyone at

      any physical distance beyond inches (if that) cannot know what

      those multi-GHz timestamps are going to be. And every interrupt or

      two has to include a bit or two of entropy. And if there are a lot

      of interrupts happening, that's real. Hash or encrypt it and

      that's a quality RNG.</p>

    <p><br>

    </p>

    <p>-kb, the Kent who asserts that as security holes go, RNGs usually

      work well provided (1) they aren't crap in the first place and (2)

      they are actually hooked up.</p>

  </body>

</html>