Re: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?
"Mark D. Baushke" <[email protected]> Mon, 13 Jul 2020 13:53:47 -0700
| Newsgroups | gmane.ietf.secsh,gmane.ietf.curdle |
|---|---|
| Message-ID | <[email protected]> |
Hi Mouse, Mouse <[email protected]> writes: > > * diffie-hellman-group14-sha256 > > [It is not clear to me how much longer 2048-bits will be considered > > strong enough.] > > Surely it wouldn't be that big a deal to generate a prime of, say, 4k > bits, or whatever size gives people suitably warm fuzzies, to replace > the current group-14 prime? It is not hard to generate FFC DH parameter sets. The issue is that many folks are paranoid that someone will create a DH Backdoor How to Backdoor Diffie-Hellman https://eprint.iacr.org/2016/644 See also URL: https://github.com/mimoo/Diffie-Hellman_Backdoor The RFC4419 code in fact provides for a method to help SSH by giving us as many different ephemeral parameter sets as a server may wish to generate. > I'd be happy to do the crucnhing for it, and I can't be the only > person with RNG hardware and enough spare cycles to invest in whatever > level of primality assurance keeps people happy. We already have a number of alternatives for larger sizes we could use taken from RFC 3526 (group15, group16, group17, group18) which are based on the ration of a cirlce's circumference to its diamete ("pi"). I suppose we could also adopt RFC 7919 based on natural logarithm ("e"). Someone could also generate a new set of safe primes based on some other transcendental number (square root of "2" or some other number). My question is if we should literally require all SSH implementations to have a Mandatory To Implement (MTI) DH parameter set now which may need to be deprecated in a 'short' (for some value of the word short) period of time. Personally, I like FFC DH. I would not mind seeing Diffie-Hellman-group16-sha512 (a 4096-bit prime) as an MTI for SSH. However, denis bider <[email protected]> wrote: > I do not agree with this one: > > > diffie-hellman-group16-sha512 MUST > > I find this too computationally expensive to justify "MUST" for > servers. Last time I checked, this costs about 100 ms in server CPU > time, more on weaker CPUs, and makes it trivial to DoS a > resource-constrained server - no DDoS needed. Be safe, stay healthy, -- Mark