linux-kernel - Re: for stable -- random: use chacha20 for get_random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170410150427.GB18751@kroah.com>
Date:   Mon, 10 Apr 2017 17:04:27 +0200
From:   Greg KH <greg@...ah.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     stable@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: for stable -- random: use chacha20 for get_random_int/long

On Fri, Apr 07, 2017 at 05:27:40AM +0200, Jason A. Donenfeld wrote:
> Given that the below commit isn't very big and adds a nice security
> property (in addition to performance), it might be worthwhile to
> backport this to 4.9 stable. It's not a candidate for 4.4, since that
> kernel doesn't use chacha for the rng at all.
> 
> As this is in random.c, it's Ted's and Greg's judgement call.
> 
> commit f5b98461cb8167ba362ad9f74c41d126b7becea7
> Author: Jason A. Donenfeld <Jason@...c4.com>
> Date:   Fri Jan 6 19:32:01 2017 +0100
> 
>    random: use chacha20 for get_random_int/long
> 
>    Now that our crng uses chacha20, we can rely on its speedy
>    characteristics for replacing MD5, while simultaneously achieving a
>    higher security guarantee. Before the idea was to use these functions if
>    you wanted random integers that aren't stupidly insecure but aren't
>    necessarily secure either, a vague gray zone, that hopefully was "good
>    enough" for its users. With chacha20, we can strengthen this claim,
>    since either we're using an rdrand-like instruction, or we're using the
>    same crng as /dev/urandom. And it's faster than what was before.
> 
>    We could have chosen to replace this with a SipHash-derived function,
>    which might be slightly faster, but at the cost of having yet another
>    RNG construction in the kernel. By moving to chacha20, we have a single
>    RNG to analyze and verify, and we also already get good performance
>    improvements on all platforms.
> 
>    Implementation-wise, rather than use a generic buffer for both
>    get_random_int/long and memcpy based on the size needs, we use a
>    specific buffer for 32-bit reads and for 64-bit reads. This way, we're
>    guaranteed to always have aligned accesses on all platforms. While
>    slightly more verbose in C, the assembly this generates is a lot
>    simpler than otherwise.
> 
>    Finally, on 32-bit platforms where longs and ints are the same size,
>    we simply alias get_random_int to get_random_long.
> 
>    Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
>    Suggested-by: Theodore Ts'o <tytso@....edu>
>    Cc: Theodore Ts'o <tytso@....edu>
>    Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>
>    Cc: Andy Lutomirski <luto@...capital.net>
>    Signed-off-by: Theodore Ts'o <tytso@....edu>

Seems reasonable to me, now queued up, thanks!

greg k-h