Re: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?

["Mark D. Baushke" <[e-mail]>]

Hi Mouse,

Mouse <[e-mail]> 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 <[e-mail]> 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