[Cryptography] Opening Discussion: Speculation on "BULLRUN"

ianG iang at iang.org
Fri Sep 6 04:52:37 EDT 2013


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


More information about the cryptography mailing list