lkml.org 
[lkml]   [2014]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 02/03]: hwrng: create filler thread
    [cc: Greg Price, might be working on this stuff]

    On Wed, Mar 26, 2014 at 6:03 PM, H. Peter Anvin <hpa@zytor.com> wrote:
    > I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...

    TBH I'm highly skeptical of this kind of entropy estimation.
    /dev/random is IMO just silly, since you need to have very
    conservative entropy estimates for the concept to really work, and
    that ends up being hideously slow. Also, in the /dev/random sense,
    most hardware RNGs have no entropy at all, since they're likely to be
    FIPS-approved DRBGs that don't have a real non-deterministic source.

    For the kernel's RNG to be secure, I think it should have the property
    that it still works if you rescale all the entropy estimates by any
    constant that's decently close to 1.

    If entropy estimates are systematically too low, then a naive
    implementation results in an excessively long window during early
    bootup in which /dev/urandom is completely insecure.

    If entropy estimates are systematically too high, then a naive
    implementation fails to do a catastrophic reseed, and the RNG can be
    brute-forced.

    So I think that the core code should do something along the lines of
    using progressively larger reseeds. Since I think that /dev/random is
    silly, this means that we only really care about the extent to which
    "entropy" measures entropy conditioned on whatever an attacker can
    actually compute. Since this could vary widely between devices (e.g.
    if your TPM is malicious), I think that the best we can do is to
    collect ~256 bits from everything available, shove it all in to the
    core together, and repeat. For all I know, the core code already does
    this.

    The upshot is that the actual rescaling factor should barely matter.
    50% is probably fine. So is 100% and 25%. 10% is probably asking for
    trouble during early boot if all you have is a TPM.

    --Andy


    \
     
     \ /
      Last update: 2014-03-27 02:41    [W:2.679 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site