Hey folks,
Thought I should mention here that I've written up the various RNG
things I've been working on for 5.17 & 5.18 here:
https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ .
Feel free to discuss on list here if you'd like, or if you see
something you don't like, I'll happily review patches!
Regards,
Jason
Jason A. Donenfeld <[email protected]> wrote:
> Thought I should mention here that I've written up the various RNG
> things I've been working on for 5.17 & 5.18 here:
> https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ .
>
> Feel free to discuss on list here if you'd like, or if you see
> something you don't like, I'll happily review patches!
Your code includes:
enum {
POOL_BITS = BLAKE2S_HASH_SIZE * 8,
POOL_MIN_BITS = POOL_BITS /* No point in settling for less. */
};
static struct {
struct blake2s_state hash;
spinlock_t lock;
unsigned int entropy_count;
} input_pool = {
.hash.h = { BLAKE2S_IV0 ^ (0x01010000 | BLAKE2S_HASH_SIZE),
BLAKE2S_IV1, BLAKE2S_IV2, BLAKE2S_IV3, BLAKE2S_IV4,
BLAKE2S_IV5, BLAKE2S_IV6, BLAKE2S_IV7 },
.hash.outlen = BLAKE2S_HASH_SIZE,
.lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
};
As far as I can tell, you have eliminated the 4K-bit input pool
that this driver has always used & are just using the hash
context as the input pool. To me, this looks like an error.
A side effect of that is losing the latent-entropy attribute
on input_pool[] so we no longer get initialisation from
the plugin. Another error.
Sandy Harris <[email protected]> wrote:
> Jason A. Donenfeld <[email protected]> wrote:
>
> > Thought I should mention here that I've written up the various RNG
> > things I've been working on for 5.17 & 5.18 here:
> > https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ .
> >
> > Feel free to discuss on list here if you'd like, or if you see
> > something you don't like, I'll happily review patches!
>
> Your code includes:
>
> enum {
> POOL_BITS = BLAKE2S_HASH_SIZE * 8,
> POOL_MIN_BITS = POOL_BITS /* No point in settling for less. */
> };
>
> static struct {
> struct blake2s_state hash;
> spinlock_t lock;
> unsigned int entropy_count;
> } input_pool = {
> .hash.h = { BLAKE2S_IV0 ^ (0x01010000 | BLAKE2S_HASH_SIZE),
> BLAKE2S_IV1, BLAKE2S_IV2, BLAKE2S_IV3, BLAKE2S_IV4,
> BLAKE2S_IV5, BLAKE2S_IV6, BLAKE2S_IV7 },
> .hash.outlen = BLAKE2S_HASH_SIZE,
> .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
> };
>
> As far as I can tell, you have eliminated the 4K-bit input pool
> that this driver has always used & are just using the hash
> context as the input pool. To me, this looks like an error.
>
> A side effect of that is losing the latent-entropy attribute
> on input_pool[] so we no longer get initialisation from
> the plugin. Another error.
I could see reasonable arguments for reducing the size of
the input pool since that would save both kernel memory
and time used by the hash. Personally, though, I would
not consider anything < 2Kbits without seeing strong
arguments to justify it.
You seem to have gone to 512 bits without showing
any analysis to justify it. Have I just missed them?
On Thu, Mar 24, 2022 at 4:29 AM Sandy Harris <[email protected]> wrote:
> > > Thought I should mention here that I've written up the various RNG
> > > things I've been working on for 5.17 & 5.18 here:
> > > https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ .
> > >
> > > Feel free to discuss on list here if you'd like, or if you see
> > > something you don't like, I'll happily review patches!
> >
> > Your code includes:
> >
> > enum {
> > POOL_BITS = BLAKE2S_HASH_SIZE * 8,
> > POOL_MIN_BITS = POOL_BITS /* No point in settling for less. */
> > };
> >
> > static struct {
> > struct blake2s_state hash;
> > spinlock_t lock;
> > unsigned int entropy_count;
> > } input_pool = {
> > .hash.h = { BLAKE2S_IV0 ^ (0x01010000 | BLAKE2S_HASH_SIZE),
> > BLAKE2S_IV1, BLAKE2S_IV2, BLAKE2S_IV3, BLAKE2S_IV4,
> > BLAKE2S_IV5, BLAKE2S_IV6, BLAKE2S_IV7 },
> > .hash.outlen = BLAKE2S_HASH_SIZE,
> > .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
> > };
> >
> > As far as I can tell, you have eliminated the 4K-bit input pool
> > that this driver has always used & are just using the hash
> > context as the input pool. To me, this looks like an error.
> >
> > A side effect of that is losing the latent-entropy attribute
> > on input_pool[] so we no longer get initialisation from
> > the plugin. Another error.
>
> I could see reasonable arguments for reducing the size of
> the input pool since that would save both kernel memory
> and time used by the hash. Personally, though, I would
> not consider anything < 2Kbits without seeing strong
> arguments to justify it.
>
> You seem to have gone to 512 bits without showing
> any analysis to justify it. Have I just missed them?
Explanation in <https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=6e8ec2552c7d>.
There's also a link to a paper in there.
Jason