51–60 of 100 posts
Earlier quoted context omitted.
[deleted]
my understanding (and i'm not an expert - just trying to help with the discussion) is that getting sufficient entropy is quite hard. i vaguely remember at least one issue, perhaps on startup, where there was insufficient entropy to do something, and so people switched to some other less random source and screwed everything. so if this reports unlimited (or at least, larger than anything else) entropy then there are l…
Earlier quoted context omitted.
my understanding (and i'm not an expert - just trying to help with the discussion) is that getting sufficient entropy is quite hard. i vaguely remember at least one issue, perhaps on startup, where there was insufficient entropy to do something, and so people switched to some other less random source and screwed everything. so if this reports unlimited (or at least, larger than anything else) entropy then there are l…
[deleted]
i was trying to explain why an untrusted hardware rng cannot be improved in some cases (because of limited entropy from elsewhere). and i don't see how what you are saying addresses that.
Further down the thread: > Not to mention, Intel have been in bed with the NSA for the longest time. > Secret areas on the chip, pop instructions, microcode and all that ... What does "pop instructions" refer to here?
And here is the mailing list thread that the author refers to: https://lkml.org/lkml/2011/7/29/366
There was a lot more follow-up later, see e.g. https://lkml.org/lkml/2012/7/5/422 The important commit here is: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... Excerpted: Change get_random_bytes() to not use the HW RNG, even if it is avaiable. The reason for this is that the hw random number generator is fast (if it is present), but it requires that we trust the hardware manufacturer to have not put i…
Earlier quoted context omitted.
You are right that closed source doesn't mean its insecure - on the other hand, open source could prove that it is indeed secure. With new scandals coming up every week these days, about hidden backdoors in security software, I trust open source more than ever before.
Open source would not prove it is secure. At best, you could look for obvious attacks. Cryptography is hard.
https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND. I still don't get it.
In NIST parlance (SP800-90{A,B,C}), RDRAND is a DRBG, while /dev/random should be a NRBG. For what it's worth, the RDSEED instruction has been announced by Intel a while back (but not yet on current processors), which means to be an NRBG as well.
https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND. I still don't get it.
What don't you get? RDRAND is an interface to a non-blocking PRNG backed by a HWRNG. You can't directly get the output of the HWRNG. Intel uses the PRNG to condition the output of the HWRNG, but it will still give you numbers if the HWRNG is having trouble (HWRNG errors can be detected, but the RDRAND instruction itself doesn't trap on HWRNG failures). If you trust Intel's PRNG sufficiently, then you can use RDRAND d…
this is my favourite conspiracy theory that the CPUs are backdoored. just assign a bunch of registers with some special values and execute a specific instruction and the CPU will drop all memory protection. take something like google's NACL or a javascript JIT where you have enough control over the registers and you have a permanent browser exploit.
They'd looks something like Debian's OpenSSL. But I believe that was not an intentional backdoor.
https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND. I still don't get it.
What don't you get? RDRAND is an interface to a non-blocking PRNG backed by a HWRNG. You can't directly get the output of the HWRNG. Intel uses the PRNG to condition the output of the HWRNG, but it will still give you numbers if the HWRNG is having trouble (HWRNG errors can be detected, but the RDRAND instruction itself doesn't trap on HWRNG failures). If you trust Intel's PRNG sufficiently, then you can use RDRAND d…