[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jack Hill
Subject: Re: maradns reproducibility fixes and the merits of picking a random number
Date: Tue, 28 Jun 2022 11:39:47 -0400 (EDT)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

On Tue, 28 Jun 2022, Efraim Flashner wrote:
On Mon, Jun 27, 2022 at 06:31:41PM -0700, Vagrant Cascadian wrote:

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,

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]