Re: maradns reproducibility fixes and the merits of picking a random number

[Jack Hill <jackhill@jackhill.us>]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Tue, 28 Jun 2022, Efraim Flashner wrote:
> On Mon, Jun 27, 2022 at 06:31:41PM -0700, Vagrant Cascadian wrote:
>>>
>>>   https://github.com/samboy/MaraDNS/discussions/101#discussioncomment-3006487
>>
>> Upstream appears to think it is mostly ok to actually embed a specific
>> random prime... and not have it be different across all the builds, as
>> the number is mixed with other randomness from /dev/urandom.
>>
>> It is expensive to generate the random prime on some hardware, so doing
>> so at runtime might not be feasible in some cases...
>>
>> So, where do we go from here, knowing what we now know? :)
>>
>>
>> live well,
>>   vagrant
>
> I looked back at the original email. I think we should not embed a
> static random prime and mark it as non-substitutable. Then with that
> flag add a note that it generates a prime during building and everyone
> having a unique prime is more important to us than everyone having the
> same reproducible prime.

Hi, I think I lost something in the reasoning here. It sounded to me like 
upstream was OK with embedding a fixed prime, and even suggested one:

> If one’s coding style can’t have a random 32-bit number in a build, make 
> MUL_CONSTANT an unchanging number like 1748294267 (the number I use for 
> Windows builds of Deadwood). Deadwood will still be secure from hash 
> bucket collision attacks except in the very rare corner case of 
> /dev/urandom not giving out good random numbers.

Best,
Jack