Announcement

Collapse
No announcement yet.

New /dev/random Implementation Hits 35th Revision

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • New /dev/random Implementation Hits 35th Revision

    Phoronix: New /dev/random Implementation Hits 35th Revision

    Going on for more than four years now has been creating a new /dev/random implementation and this Friday marks the 35th revision to this big set of patches that aim for better performance and security...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It will be eventually merged because without it LRNG does not meet new FIPS requirements in next year summer.

    Comment


    • #3
      The 35th release and still not merged?
      Well, I warmly wish this a better fate than GNU HURD

      Comment


      • #4
        Originally posted by topolinik View Post
        The 35th release and still not merged?
        Well, I warmly wish this a better fate than GNU HURD
        Security is not easy. And not easy at all when changing almost the whole LRNG in a way that's not break anything existing. Needs also to take care of all low-entropy IoT devices in addition to misbehaving user space applications reading directly from /dev/random which may block.

        Comment


        • #5
          I look forward to it as I currently have to install
          rng-tools, haveged, and change defaults to use urandom.

          Comment


          • #6
            How hard could it be to just get a simple random number? Stop over-complicating it. When it comes to security, any generator that is purely based on software is a bad idea, so for anyone who actually cares about something "truly" random ought to resort to other solutions anyway.

            It's really not hard or expensive to get a totally unpredictable number. Leave /dev/random alone.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              It's really not hard or expensive to get a totally unpredictable number. Leave /dev/random alone.
              Actually, it's probably one of the harder problems in computer security. Modern CPUs include hardware randomness, but it's good to pull from a number of sources.

              I completely agree with your "it ain't broke, don't fix it" approach, though. At least the fact that it is taking them this long is a good indication that if they didn't know what they were doing at when they started, they've figured it out now...

              Comment


              • #8
                Originally posted by OneTimeShot View Post
                Actually, it's probably one of the harder problems in computer security. Modern CPUs include hardware randomness, but it's good to pull from a number of sources.
                Yes, getting a truly random number through software is indeed one of the harder problems. That's why I was implying to use an external/hardware solution. There are dozens of ways to get completely unpredictable numbers for very cheap, like tuning a radio where all you get is noise or a probe measuring radioactive decay. Anyone who is anal enough about security should never depend on a purely software solution, because as long as the algorithm can be reversed, it isn't secure. Using the cosmic microwave background or subatomic activity is a very easy and reliable way to prevent prediction, without even needing an algorithm.

                So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.
                  Entropy sources for /dev/random will be chosen by user during compile time. However none of random sources will be not allowed crediting entropy to multiple similar noise sources and that is problem in existing LRNG implementation and needs rework anyway. Every random source must be able separately to be tested which has not been possible.

                  Comment


                  • #10
                    Originally posted by schmidtbag View Post
                    So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.
                    That's not how the world works, though. We have SSL encryption to worry about now.

                    Comment

                    Working...
                    X