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. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
