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

  • Weasel
    replied
    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. :-)

    Leave a comment:


  • edgmnt
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • edgmnt
    replied
    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.

    Leave a comment:


  • miabrahams
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • edgmnt
    replied
    /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.

    Leave a comment:


  • xiando
    replied
    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

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • miabrahams
    replied
    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.

    Leave a comment:

Working...
X