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

["Gábor Boskovits" <gboskovits@gmail.com>]

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

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (időpont: 2022. jún. 28., K
18:07):

> Hi,
>
> Vagrant said:
> > It is expensive to generate the random prime on some hardware, so doing
> > so at runtime might not be feasible in some cases...
>
> But in the same reply you're paraphrasing, upstream also says:
>
> > In 2010, I updated that homegrown hash compression
> > algorithm to also add a random number when compressing
> > the input, and calculating another 32-bit random number
> > when Deadwood starts.
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> and
>
> > I believe the hash compression algorithm is protected from hash
> > bucket collision attacks, even if Deadwood is patched to make
> > MUL_CONSTANT a constant number, since the add constant
> > remains random.
>
> so their 'too computationally expensive' does not make sense to me.  Do
> they bail out if generating the truly random part 'takes too long'?  Surely
> not.
>
> Neither does the 'ah, but your urandom might be broken' argument for
> silently substituting a still less random number.
>
> I don't think this alone justifies the scheme, or disabling substitutes.
>
I tend to agree.
Afaics this can be solved in a workaround way. I don't think this random
number is picked up by the build in any way. Upstream could just provide it
as an optional config value. That would be better in every respect.  Then
they could just give a build flag to move to the new model. Do you think
such a proposal would be accepted upstream?

>
> Kind regards,
>
> T G-R
>
> Sent on the go.  Excuse or enjoy my brevity.
>
>

[-- Attachment #2: Type: text/html, Size: 2260 bytes --]