Date: Mon, 22 Nov 2021 13:03:59 -0500
On Mon, Nov 22, 2021 at 12:50 PM Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:
> On 19/11/2021 13.20, Arthur O'Dwyer via Std-Proposals wrote:
> > On Fri, Nov 19, 2021 at 1:09 PM Jason McKesson via Std-Proposals wrote:
> >> Or we could split the difference by allowing the user to provide an
> >> integer number for the maximum number of values to extract from
> >> `random_device`. Maybe even make providing the integer mandatory.
> >
> > The operation of "specifying a number of bits to take from random_device,
> > and then 'key-stretching' those into a larger seed value suitable for
> > MT19937," sounds like a perfect job for... a PRNG. ;)
> >
> > // Consume a lot of randomness from the OS to seed mt19937
> > auto g = nonstd::mt19937(std::random_device{});
> >
> > // Consume only 256 bits of randomness from the OS to seed xoshiro256ss;
> > // then consume a lot of *pseudo*-randomness from xoshiro256ss to seed
> > mt19937
> > auto g = nonstd::mt19937(nonstd::xoshiro256ss(std::random_device{}));
>
> ...which is superior to feeding MT 256 bits of initial entropy *how*
> exactly? You will still have a maximum of 2^256 possible sequences
> (albeit different ones from if you used those 256 bits directly).
Correct. I think you misunderstood the point of my message. I'm not saying
that "specifying a number of bits to take from random_device, and then
'key-stretching' those into a larger seed value suitable for MT19937,"
a.k.a. "under-seeding MT19937," is a *good* operation nor that any working
programmer should ever *want* to do it. I'm just saying that *if* you
wanted to do it, then you could easily do it via an intermediate PRNG that
takes a seed of the proper size.
The alternatives are:
- Don't do this operation at all (I like this in practice)
- Do this operation using an intermediate PRNG such as Xoshiro256** (this
is the one-liner above)
- Do this operation using some other API, not yet proposed (and I dare you
to propose an API of similar usefulness to the above, that still lets you
do this specific operation in one line)
Notice that once you've seeded the xoshiro256ss engine with its 256 bits of
entropy, you would actually do much better to* just use it directly*,
rather than use it to seed MT19937. It'll be a smaller binary, use less
CPU, etc etc, than if you drag in the MT19937 dependency. But, if like
Dimitrij you're *married* to the idea of under-seeding MT19937, you don't
*need* any not-yet-proposed API to do it; you can just do what I suggested
instead.
HTH,
Arthur
wrote:
> On 19/11/2021 13.20, Arthur O'Dwyer via Std-Proposals wrote:
> > On Fri, Nov 19, 2021 at 1:09 PM Jason McKesson via Std-Proposals wrote:
> >> Or we could split the difference by allowing the user to provide an
> >> integer number for the maximum number of values to extract from
> >> `random_device`. Maybe even make providing the integer mandatory.
> >
> > The operation of "specifying a number of bits to take from random_device,
> > and then 'key-stretching' those into a larger seed value suitable for
> > MT19937," sounds like a perfect job for... a PRNG. ;)
> >
> > // Consume a lot of randomness from the OS to seed mt19937
> > auto g = nonstd::mt19937(std::random_device{});
> >
> > // Consume only 256 bits of randomness from the OS to seed xoshiro256ss;
> > // then consume a lot of *pseudo*-randomness from xoshiro256ss to seed
> > mt19937
> > auto g = nonstd::mt19937(nonstd::xoshiro256ss(std::random_device{}));
>
> ...which is superior to feeding MT 256 bits of initial entropy *how*
> exactly? You will still have a maximum of 2^256 possible sequences
> (albeit different ones from if you used those 256 bits directly).
Correct. I think you misunderstood the point of my message. I'm not saying
that "specifying a number of bits to take from random_device, and then
'key-stretching' those into a larger seed value suitable for MT19937,"
a.k.a. "under-seeding MT19937," is a *good* operation nor that any working
programmer should ever *want* to do it. I'm just saying that *if* you
wanted to do it, then you could easily do it via an intermediate PRNG that
takes a seed of the proper size.
The alternatives are:
- Don't do this operation at all (I like this in practice)
- Do this operation using an intermediate PRNG such as Xoshiro256** (this
is the one-liner above)
- Do this operation using some other API, not yet proposed (and I dare you
to propose an API of similar usefulness to the above, that still lets you
do this specific operation in one line)
Notice that once you've seeded the xoshiro256ss engine with its 256 bits of
entropy, you would actually do much better to* just use it directly*,
rather than use it to seed MT19937. It'll be a smaller binary, use less
CPU, etc etc, than if you drag in the MT19937 dependency. But, if like
Dimitrij you're *married* to the idea of under-seeding MT19937, you don't
*need* any not-yet-proposed API to do it; you can just do what I suggested
instead.
HTH,
Arthur
Received on 2021-11-22 12:04:12