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: <CAHmME9pBXXfhpGngu5GRVF8BRx57VYP4w4W9m=B33zW7AVE9Ng@mail.gmail.com>
Date:   Tue, 22 Mar 2022 11:25:48 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: skip fast_init if hwrng provides large chunk of entropy

Hi Dominik,

On Tue, Mar 22, 2022 at 12:45 AM Dominik Brodowski
<linux@...inikbrodowski.net> wrote:
> Well, so far, we need 64 bytes input to the fast init stage, and then
> further 32 bytes of randomness to proceed to full init, and we used to mix
> the former into the latter, which provided for some sort of extra margin.
> But as we don't seem to do that any more (mixing some of base_crng back into
> the input_pool), that exercise may have become pointless.

"Some extra margin" but you're comparing 512 bits to 768 bits? That
makes no sense. 256 bits alone would be sufficient here. The whole
point of CONFIG_RANDOM_TRUST_BOOTLOADER=y is that the kernel builder
has chosen to trust the seed that comes from the bootloader. If it's
not trusted, then it goes through add_device_randomness(), which
doesn't have anything to do with fast init or the main init.

The purpose of "fast init" being separate from the full thing is so
that you can't brute force inputs bit by bit. Having a massive tranche
of 512 bits of entropy makes that brute forcing impossible; therefore
it doesn't make sense to do the fast init thing in that case.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ