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

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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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


    Leave a comment:


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

    Originally posted by mb_q View Post
    But no, RDRAND must be for 'security', so it is wrapped in some kind of a hardware PRNG and thus slower than many software PRNGS. On the other hand, while it most likely has no backdoor (it is literally the worse possible place in a CPU to put such), it cannot be ever trusted by anyone sane because it is perfectly closed.
    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...

    Leave a comment:


  • oleid
    replied
    It's not like the RN of those HW-RNGs are used directly. They're used to fill the pool of entropy used by entropy based RNGs. And the funny thing is: Adding non-random data to entropy pools doesn't lower the entropy. It merely doesn't increase it.

    Leave a comment:


  • chithanh
    replied
    Originally posted by Adarion View Post
    As far as I know it's been relatively few, I only recall Loongson. Now there are a few more coming in the x86 area, the AMD dervied one(s) and via VIA's x86 license.
    FeiTeng (Sparc, ARM)
    Loongson (MIPS)
    Shenwei/Sunway (Alpha, custom ISA)

    The Sunway SW26010 powered the leading Top500 system between June 2016 - June 2018.

    Leave a comment:

Working...
X