Announcement

Collapse
No announcement yet.

Linux 5.6 Seeing Random Changes, New "Insecure" Option With GRND_INSECURE

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

  • Linux 5.6 Seeing Random Changes, New "Insecure" Option With GRND_INSECURE

    Phoronix: Linux 5.6 Seeing Random Changes, New "Insecure" Option With GRND_INSECURE

    The recent work by longtime kernel developer Andy Lutomirski on improving Linux's random APIs and introducing a new "GRND_INSECURE" option is now queued into the random dev queue ahead of the Linux 5.6 cycle...

    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
    "Linux 5.6 Seeing Random Changes" Scary!!!

    (It's a joke)

    Comment


    • #3
      Don’t get it. If you want best effort, use /dev/urandom. why break the /dev/random functionality?

      if you want to break your own box, just symlink /dev/random to /dev/urandom

      there is (hopefully) some better rationale here...

      Comment


      • #4
        Originally posted by OneTimeShot View Post
        Don’t get it. If you want best effort, use /dev/urandom. why break the /dev/random functionality?
        It's not breaking /dev/random, it's improving it by making it never block once it has been initialized. That is, it gets rid of the old idea that reading from /dev/random somehow depletes entropy.

        Comment


        • #5
          > it's not anticipated that these changes should break anything

          Isn't that always the case for check-ins ...

          Comment


          • #6
            Originally posted by jabl View Post

            It's not breaking /dev/random, it's improving it by making it never block once it has been initialized. That is, it gets rid of the old idea that reading from /dev/random somehow depletes entropy.
            There's a reason entropy for /dev/random matters. Has this reason gone away, or have people just given up on the idea of cryptographic security?

            Comment


            • #7
              Originally posted by chroma View Post

              There's a reason entropy for /dev/random matters. Has this reason gone away, or have people just given up on the idea of cryptographic security?
              Essentially, increased trust in CSPRNG algorithms, which are designed to never allow an attacker reconstruct the internal state by observing the output. That is, if you trust your CSPRNG, once you have initialized it properly, using it doesn't consume the entropy in the initial seed.

              Or IOW, more likely that people cause a DOS by exhausting entropy or breaking their security via some ill-advised hack to avoid said DOS, than the CSPRNG algorithm being broken.

              Comment


              • #8
                Originally posted by jabl View Post

                Essentially, increased trust in CSPRNG algorithms, which are designed to never allow an attacker reconstruct the internal state by observing the output. That is, if you trust your CSPRNG, once you have initialized it properly, using it doesn't consume the entropy in the initial seed.

                Or IOW, more likely that people cause a DOS by exhausting entropy or breaking their security via some ill-advised hack to avoid said DOS, than the CSPRNG algorithm being broken.
                It's not only an algorithm. There are many security standards and requirements, like NIST SP800-90A. Now it seems Linux TRNG will not meet the requirements. That also means Linux kernel will be not FIPS complian either.

                Comment


                • #9
                  Originally posted by jabl View Post

                  Essentially, increased trust in CSPRNG algorithms, which are designed to never allow an attacker reconstruct the internal state by observing the output. That is, if you trust your CSPRNG, once you have initialized it properly, using it doesn't consume the entropy in the initial seed.

                  Or IOW, more likely that people cause a DOS by exhausting entropy or breaking their security via some ill-advised hack to avoid said DOS, than the CSPRNG algorithm being broken.
                  But I like having to move my mouse around and running find / when generating keys!

                  Comment


                  • #10
                    Originally posted by jabl View Post
                    It's not breaking /dev/random, it's improving it by making it never block once it has been initialized. That is, it gets rid of the old idea that reading from /dev/random somehow depletes entropy.
                    i.e. by replacing random numbers with prng. but everyone can do it in software without kernel help. or with kernel (/dev/urandom) help. btw, to get a feeling how good new idea is you just have to check how it's spelled GRND_INSECURE
                    Last edited by pal666; 08 January 2020, 05:57 PM.

                    Comment

                    Working...
                    X