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

  • #21
    /dev/urandom is already quite slow and it has nothing to do with the entropy source. You can get better throughput with OpenSSL running AES in CTR mode entirely in userspace.

    /dev/urandom should provide crypto-grade random numbers and should block if it has not been seeded with a minimum amount of entropy.

    Comment


    • #22
      Originally posted by edgmnt View Post
      /dev/urandom should provide crypto-grade random numbers and should block if it has not been seeded with a minimum amount of entropy.
      Did you mean /dev/random? urandom doesn't block. Anyway, urandom is perfectly fine for crypto purposes, /dev/random is quite silly, but there's enough of that proven online I'm not going to bother here anymore.

      Basically it boils down to:
      • Quality random numbers
      • Fast "random" number generation
      Pick one.

      Comment


      • #23
        Originally posted by Weasel View Post
        String concatenation? What?

        You clearly missed the most obvious and common one though: XOR.
        Xor, add 2.5, multiply by 10^8, it's still just one bit of entropy.

        Comment


        • #24
          Originally posted by Weasel View Post
          Did you mean /dev/random? urandom doesn't block. Anyway, urandom is perfectly fine for crypto purposes, /dev/random is quite silly, but there's enough of that proven online I'm not going to bother here anymore.

          Basically it boils down to:
          • Quality random numbers
          • Fast "random" number generation
          Pick one.
          No, I really mean /dev/urandom. There's a bit of confusion on this topic, so let me clarify: /dev/random blocks when you try to read more than the available entropy (which counts as "consumed"), while /dev/urandom does not. But both should block if the entropy pool hasn't been initialized properly with a minimum amount of entropy in the first place. No CSPRNG is secure with a predictable (zero entropy) initial state/seed, which is why it needs to block. If /dev/urandom doesn't block at all (last time I look it only printed a warning), then it's horribly broken.

          Comment


          • #25
            Originally posted by edgmnt View Post

            No, I really mean /dev/urandom. There's a bit of confusion on this topic, so let me clarify: /dev/random blocks when you try to read more than the available entropy (which counts as "consumed"), while /dev/urandom does not. But both should block if the entropy pool hasn't been initialized properly with a minimum amount of entropy in the first place. No CSPRNG is secure with a predictable (zero entropy) initial state/seed, which is why it needs to block. If /dev/urandom doesn't block at all (last time I look it only printed a warning), then it's horribly broken.
            How is that possible?

            Doesn't Linux (or systemd, whatever) save the previous seed on boot (and shutdown) and reload it next time it's booted?

            Even on read-only media, it should still have a unique seed that's never shared, ever.

            Comment


            • #26
              Originally posted by Weasel View Post
              How is that possible?

              Doesn't Linux (or systemd, whatever) save the previous seed on boot (and shutdown) and reload it next time it's booted?
              Consider install media, for example. You can't just distribute the same pre-seeded ISO to everybody (the seed won't be secret anymore), although you could tell them to use a tool to pre-seed the CD / USB drive before booting it.

              Although you can generate a fresh seed in almost every case I can think of, people just don't bother in practice. This is why they keep complaining about blocking for entropy at boot time.

              Originally posted by Weasel View Post
              Even on read-only media, it should still have a unique seed that's never shared, ever.
              A unique seed isn't quite enough. It also needs to be secret and you can't reuse it on every boot. You do need a RNG if you have no persistent writable storage whatsoever.

              Comment


              • #27
                Originally posted by edgmnt View Post
                Consider install media, for example. You can't just distribute the same pre-seeded ISO to everybody (the seed won't be secret anymore), although you could tell them to use a tool to pre-seed the CD / USB drive before booting it.
                Yeah, you're right, I forgot about shared install media.

                Unique seed is definitely enough if it's not shared (i.e. secret and only for a single device). That's what I meant there, but that's not possible on install media I guess. :-)

                Comment

                Working...
                X