Announcement

Collapse
No announcement yet.

Linux Kernel Diverts Question To Distros: Trust CPU Hardware Random Number Generators?

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

  • #11
    Originally posted by Weasel View Post
    You do realize RDRAND is an instruction available for user-space right? So what stops you from using it no matter the distro's decision? ffs just use inline asm or an intrinsic and you have it.

    Software PRNGs are terrible because they are seeded only once or so in most applications, compared to RDRAND, at least according to its specs, obviously we don't know if it truly lives up to its specs, but there's no proof to the contrary either. RDRAND can be thought of as true randomness in a way; impossible to predict. Software PRNGs will *never* achieve this.

    Of course you can claim backdoors and all that but that doesn't make it weaker than software PRNGs, just not as good as the specs suggest. There's no proof, either, so...
    I could, but RDRAND is very slow, even compared with very good software PRNGs executing tens of instructions: https://en.wikipedia.org/wiki/RdRand#Performance
    Predictability is only important for crypto; other uses basically only require certain amount of multi-dimensional uniformity (ideal RNG is uniform in any space). But that applications do care about performance, hence would benefit from hypothetical RDRAND which is faster than software and marked insecure, rather than slow and pretending to be trustworthy. Hence I consider Intel design decisions to be misguided. Unfortunately AMD implemented RDRAND the same way, and made it even slower.


    Comment


    • #12
      Obligatory shilling for the ChaosKey, a open source and open hardware, hardware RNG dongle http://altusmetrum.org/ChaosKey/

      Comment


      • #13
        Originally posted by kpedersen View Post
        It is a very sad state of affairs when we don't trust the people we *have* to rely on. Doesn't that more make them our captors than our vendors?
        Isn't this true of all closed source logic, whether in hardware or software? And therefore in the absence of a known flaw or back-door, there's nothing new to see here. Either you opt to trust it, or you don't.

        For the truly paranoid, there are commercially available external random number generators that attach via USB. Or you could build your own.
        Last edited by torsionbar28; 16 August 2018, 05:57 PM.

        Comment


        • #14
          Originally posted by mb_q View Post
          I could, but RDRAND is very slow, even compared with very good software PRNGs executing tens of instructions: https://en.wikipedia.org/wiki/RdRand#Performance
          Predictability is only important for crypto; other uses basically only require certain amount of multi-dimensional uniformity (ideal RNG is uniform in any space). But that applications do care about performance, hence would benefit from hypothetical RDRAND which is faster than software and marked insecure, rather than slow and pretending to be trustworthy. Hence I consider Intel design decisions to be misguided. Unfortunately AMD implemented RDRAND the same way, and made it even slower.
          RDRAND is not for performance random number generation. It's for quality random numbers.

          And some of us are content with it and perfectionists. I love it, for non cryptographic purposes. Screw software PRNGs, because they're pseudo random.

          Comment


          • #15
            Originally posted by torsionbar28 View Post
            Isn't this true of all closed source logic, whether in hardware or software? And therefore in the absence of a known flaw or back-door, there's nothing new to see here. Either you opt to trust it, or you don't.
            Generic instructions are hard to make malicious, like say an "add" instruction or a "subtract" instruction. The processor would have to waste a ton of processing power to actually understand what is the "add" instruction it has to compromise, and in what way, to screw your application up.

            If it's an instruction that does have someting to do with security, like say a "move this data to secure storage register 1" then yeah, it could be made malicious easily, as you have no way of knowing if it really does not have secret instructions to let some other application access these registers, or if this instruction triggers other undocumented operations that send your data to the NSA with a SMS or something.

            Comment


            • #16
              Originally posted by torsionbar28 View Post
              Isn't this true of all closed source logic, whether in hardware or software? And therefore in the absence of a known flaw or back-door, there's nothing new to see here. Either you opt to trust it, or you don't.

              For the truly paranoid, there are commercially available external random number generators that attach via USB. Or you could build your own.
              It's true of open source software too. Just look at Speck - it's open source and no one can point to any actual problems with it, yet a significant number of people are convinced it's compromised anyway. Most people just don't have the expertise in crypto for there to be any difference between open or closed - you either trust the org that provided it, or you don't.

              Comment


              • #17
                Why don`t just add some salt to RDRAND result from thermal and voltage sensors?

                Comment


                • #18
                  Originally posted by nikolobok View Post
                  Why don`t just add some salt to RDRAND result from thermal and voltage sensors?
                  If you combine one bit of entropy with one non-random number by a typical operation like addition, multiplication or string concatenation, the total entropy is still just one bit. You gained no additional randomness by doing so.

                  Comment


                  • #19
                    Originally posted by miabrahams View Post
                    If you combine one bit of entropy with one non-random number by a typical operation like addition, multiplication or string concatenation, the total entropy is still just one bit. You gained no additional randomness by doing so.
                    String concatenation? What?

                    You clearly missed the most obvious and common one though: XOR.

                    Comment


                    • #20
                      Originally posted by mb_q View Post
                      This is so terribly stupid; there are tons of uses for even a non-trusted but fast HWRNG, like rendering, machine learning, scientific/business simulations; register-access latency class RNG with infinite cycle and no dumb artefacts would be groundbreaking.
                      It seems obvious that your complaint can be addressed by having two interfaces for random, like /dev/urandom and /dev/semi-random or /dev/probably-random or /dev/untrusted-random

                      you clearly don't want terrorist organizations like the FSB, FBI, GCHQ or SAPO to be able to use a bad random seed to get access to your private life but like you say, sometimes it doesn't matter how random it really is as long as there's jitter so having one for each use-case makes sense

                      you should get on this and submit patches

                      Comment

                      Working...
                      X