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  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]
Date:	Wed, 30 Jul 2014 13:55:48 -0700 (PDT)
From:	David Miller <>
Subject: Re: [PATCH net-next] random32: mix in entropy from core to late

From: Daniel Borkmann <>
Date: Mon, 28 Jul 2014 14:01:38 +0200

> From: Hannes Frederic Sowa <>
> Currently, we have a 3-stage seeding process in prandom():
> Phase 1 is from the early actual initialization of prandom()
> subsystem which happens during core_initcall() and remains
> most likely until the beginning of late_initcall() phase.
> Here, the system might not have enough entropy available
> for seeding with strong randomness from the random driver.
> That means, we currently have a 32bit weak LCG() seeding
> the PRNG status register 1 and mixing that successively
> into the other 3 registers just to get it up and running.
> Phase 2 starts with late_initcall() phase resp. when the
> random driver has initialized its non-blocking pool with
> enough entropy. At that time, we throw away *all* inner
> state from its 4 registers and do a full reseed with strong
> randomness.
> Phase 3 starts right after that and does a periodic reseed
> with random slack of status register 1 by a strong random
> source again.
> A problem in phase 1 is that during bootup data structures
> can be initialized, e.g. on module load time, and thus access
> a weakly seeded prandom and are never changed for the rest
> of their live-time, thus carrying along the results from a
> week seed. Lets make sure that current but also future users
> access a possibly better early seeded prandom.
> This patch therefore improves phase 1 by trying to make it
> more 'unpredictable' through mixing in seed from a possible
> hardware source. Now, the mix-in xors inner state with the
> outcome of either of the two functions arch_get_random_{,seed}_int(),
> preferably arch_get_random_seed_int() as it likely represents
> a non-deterministic random bit generator in hw rather than
> a cryptographically secure PRNG in hw. However, not all might
> have the first one, so we use the PRNG as a fallback if
> available. As we xor the seed into the current state, the
> worst case would be that a hardware source could be unverifiable
> compromised or backdoored. In that case nevertheless it
> would be as good as our original early seeding function
> prandom_seed_very_weak() since we mix through xor which is
> entropy preserving.
> Joint work with Daniel Borkmann.
> Signed-off-by: Daniel Borkmann <>
> Signed-off-by: Hannes Frederic Sowa <>

Looks great, applied, thanks everyone.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists