On 6/09/13 08:04 AM, John Kelsey wrote:
It is possible Dual EC DRBG had its P and Q values generated to insert a
trapdoor, though I don't think anyone really knows that (except the people who
generated it, but they probably can't prove anything to us at this point).
It's also immensely slower than the other DRBGs, and I have a hard time seeing
why anyone would use it. (But if you do, you should generate your own P and Q.)
Think bigger picture, think about the intervention possibilities.
E.g., when the NSA goes to a major commercial supplier who is about to
ship some product that is SP 800-90, they can agree to indeed do that,
but switch around to the Dual EC DBRG. And still maintain their
standards compliance. As it is likely a closed source, hush-hush area,
it can even be done without the adversary (who was once called the
customer) knowing.
...
Where do the world's crypto random numbers come from? My guess is
some version of the Windows crypto api and /dev/random
or /dev/urandom account for most of them.
I'm starting to think that I'd probably rather type in the results of
a few dozen die rolls every month in to my critical servers and let
AES or something similar in counter mode do the rest.
A d20 has a bit more than 4 bits of entropy. I can get 256 bits with
64 die rolls, or, if I have eight dice, 16 rolls of the group. If I
mistype when entering the info, no harm is caused. The generator can
be easily tested for correct behavior if it is simply a block cipher.
If you're trying to solve the problem of not trusting your entropy source, this
is reasonable, but it doesn't exactly scale to normal users. Entropy
collection in software is a pain in the ass, and my guess is that the
overwhelming majority of developers are happy to punt and just use the OS'
random numbers.
Right. If you don't care, just use what the OS provides. /dev/urandom
or CAPI or whatever. If you do care, you should implement a
collector-mixer-DRBG design yourself.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
