Weak DH primes and openssh

[Daniel Kahn Gillmor]

On Fri 2015-05-29 10:14:45 -0400, Hubert Kario wrote:
> On Saturday 30 May 2015 00:09:47 Damien Miller wrote:
>> On Fri, 29 May 2015, Hubert Kario wrote:
>> > Not really, no.
>> > 
>> > We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt
>> > #1". Next time we generate the primes we can use the initial seed of
>> > "2017 OpenSSH 1024 bit prime, attempt #1", but we can use just as well a
>> > "2nd generation OpenSSH 1024 bit DH parameters, try number 1". Then we
>> > can also change the algorithm to use this seed for M-R witnesses, or not.
>> > Then we can use SHA-512 instead of SHA-256, or some SHA-3 variant.
>> 
>> If you're constantly changing the parameters, then this is the opposite of
>> NUMS. Anyway, I don't think a NUMS-like approach is necessary. It certainly
>> isn't with users independently generating primality certificates.
>
> yes, I'm not saying that we should regenerate them constantly, I'm just saying 
> that if the decision was ever to do that again, it's basically impossible to 
> predict now what those numbers will be

I agree with Damien here, i don't see the point of choosing a
fixed-string seed if we're going to change it arbitrarily in the future.

And if the seed string is something semantically similar to "2017
OpenSSH 1024 bit prime, attempt #1", then there actually aren't all that
many of them to choose from, so an adversary who can do precomputation
attacks can pick the most-likely seeds and then send sockpuppets to
argue for one of them when the time comes. :/

The other alternative if you wanted fixed seeds would be to use some
high-entropy value from the real world that would be unpredictable, hard
to control, but not too hard to verify (e.g. a digest of the
concatenated UTF-8 representations of the top headline from each of the
10 highest-circulation newspapers on the day of re-generation, or
something similar).

          --dkg