• J
    random: use BLAKE2s instead of SHA1 in extraction · 9f9eff85
    Jason A. Donenfeld 提交于
    This commit addresses one of the lower hanging fruits of the RNG: its
    usage of SHA1.
    
    BLAKE2s is generally faster, and certainly more secure, than SHA1, which
    has [1] been [2] really [3] very [4] broken [5]. Additionally, the
    current construction in the RNG doesn't use the full SHA1 function, as
    specified, and allows overwriting the IV with RDRAND output in an
    undocumented way, even in the case when RDRAND isn't set to "trusted",
    which means potential malicious IV choices. And its short length means
    that keeping only half of it secret when feeding back into the mixer
    gives us only 2^80 bits of forward secrecy. In other words, not only is
    the choice of hash function dated, but the use of it isn't really great
    either.
    
    This commit aims to fix both of these issues while also keeping the
    general structure and semantics as close to the original as possible.
    Specifically:
    
       a) Rather than overwriting the hash IV with RDRAND, we put it into
          BLAKE2's documented "salt" and "personal" fields, which were
          specifically created for this type of usage.
       b) Since this function feeds the full hash result back into the
          entropy collector, we only return from it half the length of the
          hash, just as it was done before. This increases the
          construction's forward secrecy from 2^80 to a much more
          comfortable 2^128.
       c) Rather than using the raw "sha1_transform" function alone, we
          instead use the full proper BLAKE2s function, with finalization.
    
    This also has the advantage of supplying 16 bytes at a time rather than
    SHA1's 10 bytes, which, in addition to having a faster compression
    function to begin with, means faster extraction in general. On an Intel
    i7-11850H, this commit makes initial seeding around 131% faster.
    
    BLAKE2s itself has the nice property of internally being based on the
    ChaCha permutation, which the RNG is already using for expansion, so
    there shouldn't be any issue with newness, funkiness, or surprising CPU
    behavior, since it's based on something already in use.
    
    [1] https://eprint.iacr.org/2005/010.pdf
    [2] https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf
    [3] https://eprint.iacr.org/2015/967.pdf
    [4] https://shattered.io/static/shattered.pdf
    [5] https://www.usenix.org/system/files/sec20-leurent.pdfReviewed-by: NTheodore Ts'o <tytso@mit.edu>
    Reviewed-by: NEric Biggers <ebiggers@google.com>
    Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: NJean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
    Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
    9f9eff85
random.c 67.8 KB