It's not XORed. It's mixed in with a twisted LFSR which is only less wrong.
XORing works if the sources are completely statistically independent. Nothing in this world is completely statistically independent. So learn some crypto and use a proper entropy extraction algorithms. Linux should do that too.
> Is there even a way for the OS to prevent applications from using this instruction?
Yes. You use your OSly powers to be the hypervisor and put a VM trap on the instruction. Then rather than returning a random number you return an #undef or a non random number or a zero with the carry flag clear.
Don't trust a VM that traps RdRand. It is out to get you.
>a _specialized_ rng device that is easy to hack to give nonrandom numbers
Can you demonstrate this?
Using accidentally entropic sources in favor of the thing designed for the job with a comprehensive security model is demonstrating a lack of clarity of thought.
It's not that they're better at extracting nutrients, it's that they influence the body to expend more or less enery. The nutrient extraction is a side effect.
I do wish researchers would read the relevant literature before jumping to conclusions.
But it is fairly bad. The numerous 'frameworks' and 'guidelines' lack specificity and a clear certification path, while the many crypto specs are overburdened with buckets of specificity that makes certification onerous.
Part of the problem is that the NIST specs are not created with anything like a normal standards process where there are competing interests watching out for stupid stuff and jumping on it. That's how we ended up with nightmares like the key derivation spec or the inappropriate online tests in SP800-90B or the fixed block size on AES. Anything contributed from the outside had to play be predetermined rules that did not improve the specs.
Slashdot Mirror
It's not XORed. It's mixed in with a twisted LFSR which is only less wrong.
XORing works if the sources are completely statistically independent. Nothing in this world is completely statistically independent. So learn some crypto and use a proper entropy extraction algorithms. Linux should do that too.
Just the ones who put in non discoverable busses. So he got that one about right,
I think you would download the library from intel. http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
Or use one of the many libraries like OpenSSL that use it.
Or read from /dev/random, because the OS does it for you. Well partially.
What makes you think Linux's RNG is 'best practice'. There are many of us in the huge and diverse RNG designer community that think it stinks.
> Is there even a way for the OS to prevent applications from using this instruction?
Yes. You use your OSly powers to be the hypervisor and put a VM trap on the instruction. Then rather than returning a random number you return an #undef or a non random number or a zero with the carry flag clear.
Don't trust a VM that traps RdRand. It is out to get you.
Well CRI audited it. Who else do you think is in the pocket of the NSA?
http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
Well I think I would know about it if it was. I don't recollect the NSA leaning on me to put backdoors in there when I was designing it.
What's wrong with the OLED?
So people don't like being poor?
>a _specialized_ rng device that is easy to hack to give nonrandom numbers
Can you demonstrate this?
Using accidentally entropic sources in favor of the thing designed for the job with a comprehensive security model is demonstrating a lack of clarity of thought.
And why not?
Read what Linus had to say this on the LKML. His logic was and still is sound.
Fixed in the sense that no one uses it because it always blocks.
And you need a hardware RNG to get you that 128 bits. It absobloodylutely essential. Not "of limited use". It is the enabling technology.
>HW RNG is of limited use in crypto anyway.
How else do you propose to get entropy out of a deterministic system?
Are you talking about SP800-22 when you talk about 'NIST tools'?
SP800-22 is a bad spec. The Lempel Ziv test is randomness is actually broken. But we have better tools than SP800-22. TestU01, Dieharder, etc.
If you want to check for an undermined RNG you need to look for correlation between outputs across multiple devices.
Oh FFS.
The 'NSA influenced' PRNG in SP800-90A is the Dual EC DRBG.
RdRand uses the AES-CTR DRBG.
Better a vet with an encyclopedic knowledge of biochemistry than an anonymous coward.
Will the recipients of her gut bacteria be required to marry Lyle Lovett?
Check his citations. They're proper peer reviewed papers. His conclusions make sense and fit the data.
This is a FIAF thing..
http://high-fat-nutrition.blogspot.com/2007/12/fiaf-whos-fat-is-it-anyway.html
It's not that they're better at extracting nutrients, it's that they influence the body to expend more or less enery. The nutrient extraction is a side effect.
I do wish researchers would read the relevant literature before jumping to conclusions.
>NIST isn't all bad
But it is fairly bad. The numerous 'frameworks' and 'guidelines' lack specificity and a clear certification path, while the many crypto specs are overburdened with buckets of specificity that makes certification onerous.
Part of the problem is that the NIST specs are not created with anything like a normal standards process where there are competing interests watching out for stupid stuff and jumping on it. That's how we ended up with nightmares like the key derivation spec or the inappropriate online tests in SP800-90B or the fixed block size on AES. Anything contributed from the outside had to play be predetermined rules that did not improve the specs.
Or "glass underwear". Take your pick.
Actually its Pant-Y-Gwydr and its more of a restaurant than a place. It translates to "First Post"
The Zombie Hunter? Wow.
They're the original Mormons.