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. -d
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 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150529/03742283/attachment-0001.bin>
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 beI 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