[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Aug 2020 19:03:43 +0000
From: George Spelvin <lkml@....ORG>
To: Andy Lutomirski <luto@...capital.net>
Cc: netdev@...r.kernel.org, w@....eu, aksecurity@...il.com,
torvalds@...ux-foundation.org, edumazet@...gle.com,
Jason@...c4.com, luto@...nel.org, keescook@...omium.org,
tglx@...utronix.de, peterz@...radead.org, tytso@....edu,
lkml.mplumb@...il.com, stephen@...workplumber.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and
activity"
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>> - Cryptographically strong ChaCha, batched
>> - Cryptographically strong ChaCha, with anti-backtracking.
>
> I think we should just anti-backtrack everything. With the "fast key
> erasure" construction, already implemented in my patchset for the
> buffered bytes, this is extremely fast.
The problem is that this is really *amorized* key erasure, and
requires large buffers to amortize the cost down to a reasonable
level.
E,g, if using 256-bit (32-byte) keys, 5% overhead would require generating
640 bytes at a time.
Are we okay with ~1K per core for this? Which we might have to
throw away occasionally to incorporate fresh seed material?
You're right that the simplification in usage is a benefit.
Powered by blists - more mailing lists