[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: Gábor Boskovits
Subject: Re: maradns reproducibility fixes and the merits of picking a random number
Date: Tue, 28 Jun 2022 18:18:21 +0200


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

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.


> 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,


Sent on the go.  Excuse or enjoy my brevity.

reply via email to

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