linux-kernel - Re: [PATCH 2/6] crypto: DRBG - track whether DRBG was seeded with !rng_is

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 26 Oct 2021 10:41:53 +0200
From:   Stephan Müller <smueller@...onox.de>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Nicolai Stange <nstange@...e.de>
Cc:     Torsten Duwe <duwe@...e.de>, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, Nicolai Stange <nstange@...e.de>
Subject: Re: [PATCH 2/6] crypto: DRBG - track whether DRBG was seeded with !rng_is_initialized()

Am Montag, 25. Oktober 2021, 11:25:21 CEST schrieb Nicolai Stange:

Hi Nicolai,

> Currently, the DRBG implementation schedules asynchronous works from
> random_ready_callbacks for reseeding the DRBG instances with output from
> get_random_bytes() once the latter has sufficient entropy available.
> 
> However, as the get_random_bytes() initialization state can get queried by
> means of rng_is_initialized() now, there is no real need for this
> asynchronous reseeding logic anymore and it's better to keep things simple
> by doing it synchronously when needed instead, i.e. from drbg_generate()
> once rng_is_initialized() has flipped to true.
> 
> Of course, for this to work, drbg_generate() would need some means by which
> it can tell whether or not rng_is_initialized() has flipped to true since
> the last seeding from get_random_bytes(). Or equivalently, whether or not
> the last seed from get_random_bytes() has happened when
> rng_is_initialized() was still evaluating to false.
> 
> As it currently stands, enum drbg_seed_state allows for the representation
> of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and
> DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full
> reseeding operation involving both, the rather expensive jitterentropy as
> well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL
> state on the other hand implies that no reseeding at all is required for a
> !->pr DRBG variant.
> 
> Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for
> representing the condition that a DRBG was being seeded when
> rng_is_initialized() had still been false. In particular, this new state
> implies that
> - the given DRBG instance has been fully seeded from the jitterentropy
>   source (if enabled)
> - and drbg_generate() is supposed to reseed from get_random_bytes()
>   *only* once rng_is_initialized() turns to true.
> 
> Up to now, the __drbg_seed() helper used to set the given DRBG instance's
> ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument
> allowing for the specification of the to be written ->seeded value instead.
> Make the first of its two callers, drbg_seed(), determine the appropriate
> value based on rng_is_initialized(). The remaining caller,
> drbg_async_seed(), is known to get invoked only once rng_is_initialized()
> is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new
> argument to __drbg_seed().
> 
> There is no change in behaviour, except for that the pr_devel() in
> drbg_generate() would now report "unseeded" for ->pr DRBG instances which
> had last been seeded when rng_is_initialized() was still evaluating to
> false.
> 
> Signed-off-by: Nicolai Stange <nstange@...e.de>

Reviewed-by: Stephan Müller <smueller@...onox.de>

Ciao
Stephan