[deleted]
"Daytona" was built to collect all CDRs. It dates back to the '70s.
The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
21–30 of 78 posts
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#22This is one of my favorite examples showing the need for 'Nothing up my sleeve' numbers. https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number I believe NIST learned their lesson, and it was applied in the design of SHA-3: http://crypto.stackexchange.com/questions/6444/why-are-the-c...
Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#23I'm no mathematician, so this is probably a dumb question that will serve as a great example for why random programmers shouldn't write cryptosystems. However, here goes anyway. Could a cryptographer please explain why it's not feasible to use multiple such PRNG algorithms in both series and parallel, perhaps even shuffling their order dynamically, at, err, random? Surely most attacks on PRNGs are based upon the assu…
Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. - John von Neumann
The very definition of a pseudo-random number generator is that it's deterministic, i.e. an algorithm. If you know in what the state of the algorithm is, you know what the next number will be. Attempting to add some ad hoc behavior on top of crypto has two common issues:
First, adding of deterministic behavior to deterministic behavior does not in any way spontaneously add randomness (see quote). In fact, it can expose additional state on which an attack can be focused. For instance, perhaps when I learn that the system you are using is an interleaved set of numbers, I can use the starting set from each to guess the seed on which all PRNGs started. Second, crypto PRNGs that are well vetted are already at the top of the game for being apparently random in output. There shouldn't be a need to do anything like what you're suggesting, ever, with a valid PRNG. What Schneier is pointing out is that good crypt doesn't have a whiff of smell. Dual_EC_DRBG does. And, badly. Just use the others, instead.
Importantly, learn the first rule of crypto: Unless you're well versed in crypto, presume you will do a very bad job of trying to implement something yourself. Understand for what the crypto library is meant to be used, understand how to use it properly, and don't try to do something on your own. It is hard for even the experts to do it well. Some simple "why don't I just.." is practically guaranteed to have a flaw. Adding your own deterministic behavior is a sin.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#24This is one of my favorite examples showing the need for 'Nothing up my sleeve' numbers. https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number I believe NIST learned their lesson, and it was applied in the design of SHA-3: http://crypto.stackexchange.com/questions/6444/why-are-the-c...
Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.
OK, so why in the world would you use asymmetric crypto in a DRBG? It makes no sense, unless of course you wanted a system with a trapdoor hoping no one would notice.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#25This is one of my favorite examples showing the need for 'Nothing up my sleeve' numbers. https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number I believe NIST learned their lesson, and it was applied in the design of SHA-3: http://crypto.stackexchange.com/questions/6444/why-are-the-c...
Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.
In this case, it could have been done. Dual_EC_DRBG hinges on the discrete log of two points being unknown; P and Q could have been both generated verifiably at random.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#26I'm no mathematician, so this is probably a dumb question that will serve as a great example for why random programmers shouldn't write cryptosystems. However, here goes anyway. Could a cryptographer please explain why it's not feasible to use multiple such PRNG algorithms in both series and parallel, perhaps even shuffling their order dynamically, at, err, random? Surely most attacks on PRNGs are based upon the assu…
Aggregating multiple sources of randomness has the potential to conceal bugs. In the Debian/OpenSSL bug from 2008 [1], randomness was sourced from multiple locations including the current process id. The idea was that more randomness, even the minimal amount from the pid, could only increase the total entropy. However, when the primary source of randomness was eliminated through an overzealous patch, the PRNG still emitted plausible looking numbers due to the remaining sources of low quality entropy. Had the PRNG only used one high quality source of randomness, people would've noticed something strange about their generated private keys much sooner.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#27The ANU Quantum Random Number generator http://qrng.anu.edu.au/ can be used as a source of additional randomness for your server's pseudo RNG, or directly. They monitor quantum fluctuation of a vacuum to generate the random numbers at a high rate.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#28Earlier quoted context omitted.
Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.
In this case, it could have been done. Dual_EC_DRBG hinges on the discrete log of two points being unknown; P and Q could have been both generated verifiably at random.
Perhaps something like "The smallest prime number not less than the base-2 expansion of pi*2^(n - 2)".
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#29Out of curiosity, why can't we just use a series of sensors on the computer to generate random numbers? Between mouse movements, touch inputs, video camera input, microphone movements, the behavior of applications in your system and how they use resources like RAM, CPU, hard-disk, listening to all the wifi + bluetooth signals around you and munging them, etc. I would imagine that there is enough entropy coming in thr…
I'm not sure if its still that way but I know PGP used to do that on Windows 95/98. You would have to move your mouse around in a window until it generated enough entropy to generate your key. I'm pretty sure I've seen it in either ssh keygen or openssl stuff also but that might have been in a virtual machine/jail with a poor or missing /dev/random. Also I believe that is where /dev/random might get some of its infor…
I'm pretty much 100% sure that's how /dev/random works. Not only have I heard that multiple times, but once when I was installing arch linux or something, my computer ran out of random bits and told me I had to wait for it to get some more from the hardware. I don't think it actually asked me to play with the keyboard, but IIRC that's what it took. Letting it just sit there didn't seem to do the trick.
Re: The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007)
#30This is one of my favorite examples showing the need for 'Nothing up my sleeve' numbers. https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number I believe NIST learned their lesson, and it was applied in the design of SHA-3: http://crypto.stackexchange.com/questions/6444/why-are-the-c...
Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.
What do you mean? The (asymmetric) RSA algorithm has no numbers up its sleeve. All the numbers involved are created by the participants themselves.
These "numbers up ones sleeve" would only be an issue if they are part of the algorithm itself, like the S-Boxes in the (symmetric) AES algorithm.