> On Aug 8, 2020, at 8:29 AM, George Spelvin <l...@sdf.org> wrote: >
> And apparently switching to the fastest secure PRNG currently > in the kernel (get_random_u32() using ChaCha + per-CPU buffers) > would cause too much performance penalty. Can someone explain *why* the slow path latency is particularly relevant here? What workload has the net code generating random numbers in a place where even a whole microsecond is a problem as long as the amortized cost is low? (I’m not saying I won’t believe this matters, but it’s not obvious to me that it matters.) > - 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.
