lkml.org 
[lkml]   [2013]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] /dev/random: Insufficient of entropy on many architectures
    On Fri, Sep 13, 2013 at 07:36:20AM +0200, Stephan Mueller wrote:
    >
    > And here the RNG theory breaks: a whitening function (crypto function)
    > like the used SHA1 does not add entropy. Thus, the SHA1 just spreads out
    > the entropy evenly over the output buffer. As entropy can be considered
    > as a kind of percentage value, if you have, say, 10% of your input
    > buffer holding entropy, applying a whitening function, you output buffer
    > still holds 10% of entropy only.

    Well..... it's a little bit more complicated than that. What you're
    saying is aboslutely true for normal entropy that we might gather.
    For example, if a disk read might take 11, 12, or 13 milliseconds
    depending on the chaotic air currents affecting how much times it
    takes to do a read, you have at best 1.5 bits of entropy. So if the
    NSA knows that during a standard boot sequences, you will be doing a
    certain precise set of reads, it can try all of the different
    possibilities of 11/12/13 ms and try to brute force what might be
    generated by the RNG.

    This is the source of my recommendation that embedded devices should
    wait as long as possible before generating things like ssh host keys.
    The longer you wait, more uncertainty will be added to the entropy
    pool, and the harder it will be for an attacker to try to brute-force
    attack the /dev/random output.

    However, if you are worried about a malicious entropy source, things
    are a little bit different. Suppose RDRAND == AES(i++, NSA_KEY),
    where the NSA doesn't know the starting value of i. But if it get can
    get a raw RDRAND value (say, someone uses it without doing any
    whitening as a session key or as a D-H parameter), it can decrypt the
    output using the NSA_KEY, and then now that it knows i, it can brute
    force break the RDRAND output, even if it's not entirely sure how many
    times RDRAND has been called between that cleanb RDRAND value and the
    RDRAND output it is trying to break.

    In *this* case, smearing out the value of RDRAND across the entropy
    pool does help, becuase it makes it significantly harder to get a
    clean RDRAND value to decrypt.


    That being said, the much bigger problem that I'm worried about is not
    necessarily a trojan'ed RDRAND, but rather on embedded ARM and MIPS
    devices where we have unsufficient entropy, and on the first boot out
    of the box, there is no random seed file that can be fixed in at boot
    time. Mixing in personalization information (serial numbers, MAC
    addresses) which *hopefully* the NSA wouldn't know in the case of
    pervasive, bulk surveillance, is a bit of a help. But it's certainly
    no help against a direct, targetted attack.

    Regards,

    - Ted


    \
     
     \ /
      Last update: 2013-09-13 21:21    [W:4.482 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site