Thread (34 messages) 34 messages, 7 authors, 2021-11-22

Re: [PATCH 1/2] wrapper: add a helper to generate numbers from a CSPRNG

From: Junio C Hamano <hidden>
Date: 2021-11-22 09:10:35

"brian m. carlson" [off-list ref] writes:
On 2021-11-18 at 07:19:08, Junio C Hamano wrote:
quoted
Presumably csprn_bytes() grabs bytes from underlying mechanism in
smaller chunk, but would not return until it fills the buffer---ah,
your "make sure our buffer handling is correct" is primarily about
the check that we get full 1k bytes in the loop?  We ask 1k chunk 64
times and we must get full 1k chunk every time?
Yes, that's what we'd expect to happen.
quoted
What I was wondering about was the other half of the check, ensuring
all buckets[] are painted that gave us the cute 10^-100 math.
Say the buffer handling is incorrect and we read only a few bytes
instead of the full 1 KiB.  Then we'll end up filling only some of the
buckets, and the check will fail much of the time, because we won't get
sufficient number of random bytes to fill all the buckets.
... meaning (64 * a few bytes) is small enough such that some slots
in buckets[] will be left untouched (and the remainder of 1kB is
untouched --- but the buffer[] is not initialized in any way, so
it's not like such an "oops, we only fed a few bytes" bug would
leave the rest to NUL or anything)?
The check is that we got enough data that looks like random bytes over
the course of our requests.
If the check were doing so, yes, I would have understood (whether I
agreed with it or not), but the check is "if we taint each and every
bucket[] even once, we are OK", not "bucket[] should be more or less
evenly touched", and that is why I do/did not understand the test.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help