All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Spelvin <lkml@SDF.ORG>
To: Andy Lutomirski <luto@amacapital.net>
Cc: netdev@vger.kernel.org, w@1wt.eu, aksecurity@gmail.com,
	torvalds@linux-foundation.org, edumazet@google.com,
	Jason@zx2c4.com, luto@kernel.org, keescook@chromium.org,
	tglx@linutronix.de, peterz@infradead.org, tytso@mit.edu,
	lkml.mplumb@gmail.com, stephen@networkplumber.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and activity"
Date: Sat, 8 Aug 2020 19:03:43 +0000	[thread overview]
Message-ID: <20200808190343.GB27941@SDF.ORG> (raw)
In-Reply-To: <7E03D29C-2982-43C9-81E6-DB46FF4D369E@amacapital.net>

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.

  parent reply	other threads:[~2020-08-08 19:04 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-08 15:26 Flaw in "random32: update the net random state on interrupt and activity" George Spelvin
2020-08-08 17:07 ` Andy Lutomirski
2020-08-08 18:08   ` Willy Tarreau
2020-08-08 18:13   ` Linus Torvalds
2020-08-08 19:03   ` George Spelvin [this message]
2020-08-08 19:49     ` Andy Lutomirski
2020-08-08 21:29       ` George Spelvin
2020-08-08 17:44 ` Willy Tarreau
2020-08-08 18:19   ` Linus Torvalds
2020-08-08 18:53     ` Willy Tarreau
2020-08-08 20:47     ` George Spelvin
2020-08-08 20:52       ` Linus Torvalds
2020-08-08 22:27         ` George Spelvin
2020-08-09  2:07           ` Linus Torvalds
2020-08-11 16:01             ` Eric Dumazet
2020-08-08 19:18   ` Florian Westphal
2020-08-08 20:59     ` George Spelvin
2020-08-08 21:18     ` Willy Tarreau
2020-08-08 20:08   ` George Spelvin
2020-08-08 20:47     ` Linus Torvalds
2020-08-09  6:57 ` [DRAFT PATCH] random32: make prandom_u32() output unpredictable George Spelvin
2020-08-09  9:38   ` Willy Tarreau
2020-08-09 17:06     ` George Spelvin
2020-08-09 17:33       ` Willy Tarreau
2020-08-09 18:30         ` George Spelvin
2020-08-09 19:16           ` Willy Tarreau
2020-08-10 11:47           ` Willy Tarreau
2020-08-10 12:01             ` David Laight
2020-08-10 14:48               ` Willy Tarreau
2020-08-10 12:03             ` Florian Westphal
2020-08-10 14:53               ` Willy Tarreau
2020-08-10 16:31             ` Linus Torvalds
2020-08-10 16:58               ` Willy Tarreau
2020-08-10 17:45                 ` Linus Torvalds
2020-08-10 18:01                   ` Willy Tarreau
2020-08-10 21:04                   ` Willy Tarreau
2020-08-11  5:26                     ` George Spelvin
2020-08-11  5:37                       ` Willy Tarreau
2020-08-11  3:47             ` George Spelvin
2020-08-11  3:58               ` Willy Tarreau
     [not found]     ` <fdbc7d7d-cba2-ef94-9bde-b3ccae0cfaac@gmail.com>
2020-08-09 21:10       ` Marc Plumb
2020-08-09 21:48         ` Linus Torvalds
2020-08-09 13:50   ` Randy Dunlap
     [not found]   ` <CANEQ_++a4YcwQQ2XhuguTono9=RxbSRVsMw08zLWBWJ_wxG2AQ@mail.gmail.com>
2020-08-09 16:08     ` George Spelvin
  -- strict thread matches above, loose matches on Subject: below --
2020-08-12  6:03 Flaw in "random32: update the net random state on interrupt and activity" Sedat Dilek
2020-08-12  6:35 ` Sedat Dilek
2020-08-12  7:13   ` Sedat Dilek
2020-08-12 15:16 ` Eric Dumazet
2020-08-12 16:20   ` Sedat Dilek
2020-08-12 16:24     ` Eric Dumazet
2020-08-12 16:38       ` Sedat Dilek
2020-08-19  9:51         ` Sedat Dilek
2021-01-08 13:08       ` Sedat Dilek
2021-01-08 13:51         ` Sedat Dilek
2021-01-08 15:41           ` Eric Dumazet
2021-01-08 21:32             ` Sedat Dilek
     [not found] <9f74230f-ba4d-2e19-5751-79dc2ab59877@gmail.com>
2020-08-05  0:57 ` Marc Plumb
2020-08-05  1:02 ` Linus Torvalds
2020-08-05  2:49 ` Willy Tarreau
2020-08-05 15:34   ` tytso
2020-08-05 16:06     ` Marc Plumb
2020-08-05 19:38       ` Willy Tarreau
2020-08-05 22:21         ` Marc Plumb
2020-08-06  6:30           ` Willy Tarreau
2020-08-06 17:18             ` Marc Plumb
2020-08-07  7:03               ` Willy Tarreau
2020-08-07 16:52                 ` Marc Plumb
2020-08-07 17:43                   ` Willy Tarreau
     [not found]                     ` <C74EC3BC-F892-416F-A95C-4ACFC96EEECE@amacapital.net>
2020-08-07 18:04                       ` Willy Tarreau
2020-08-07 18:10                       ` Linus Torvalds
2020-08-07 19:08                         ` Andy Lutomirski
2020-08-07 19:21                           ` Linus Torvalds
2020-08-07 19:33                             ` Andy Lutomirski
2020-08-07 19:56                               ` Linus Torvalds
2020-08-07 20:16                                 ` Andy Lutomirski
2020-08-07 20:24                                   ` Linus Torvalds
2020-08-07 19:59                     ` Marc Plumb
2020-08-07 22:19                       ` Willy Tarreau
2020-08-07 22:45                         ` Marc Plumb
2020-08-07 23:11                           ` Willy Tarreau
2020-08-05 22:05       ` tytso
2020-08-05 23:03         ` Andy Lutomirski
2020-08-06 17:00         ` Marc Plumb
2020-08-05 16:24     ` Jason A. Donenfeld
2020-08-05 16:53     ` Willy Tarreau
2020-08-05 15:44   ` Marc Plumb
2020-08-05 16:39     ` Linus Torvalds
2020-08-05 23:49       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200808190343.GB27941@SDF.ORG \
    --to=lkml@sdf.org \
    --cc=Jason@zx2c4.com \
    --cc=aksecurity@gmail.com \
    --cc=edumazet@google.com \
    --cc=keescook@chromium.org \
    --cc=lkml.mplumb@gmail.com \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=stephen@networkplumber.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.