Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

[denis bider <ietf-ssh3%denisbider.com@localhost>]

It looks like we were writing at about the same time. :-)

Yes, I agree with the below.

With regard to speed - in implementations available to me (Windows CNG and Crypto++), nistp384 appears to be faster than nistp521. I can't testify to how optimized they are.

Damien Miller <djm%mindrot.org@localhost> , 2/15/2016 8:33 AM:

On Sat, 13 Feb 2016, denis bider wrote:

> Comments:
>
> - If we're being comprehensive, we should include a position with regard to
> Curve25519 and Curve448:
>
> https://tools.ietf.org/html/draft-josefsson-ssh-curves-03
>
> I suggest we take the following positions:
>
> curve25519-sha256    SHOULD
> curve448-sha256      SHOULD, or MAY?
>
> That being said:
>
> - Given the recent NSA recommendations, it seems to me it would be prudent
> to update the Curve25519/Curve448 draft, and to replace the SHA-256
> algorithm with SHA-512 for Curve448. This would create the method
> "curve448-sha512" instead of "curve448-sha256".
>
> Simon, what do you think? Could your draft be updated to do that?
>
> It seems to me that this would meet the NSA's long-term guidelines, whereas
> curve448-sha256 doesn't.

I agree that curve448-sha512 is preferable to curve448-sha256, but
not for this reason. The NSA's guidance is IMO confused, betting that
quantum computers hit some goldilocks zone of "big/fast enough to break
DLP for ~256 bit EC groups" but "too small/slow for 384 bit groups"
because they've been caught flatfooted by QC developments and don't have
real QC-resistant replacements ready yet (not that anyone would trust them
if they came from the NSA anwyay).

IMO a better justification is: curve448 is a backup against as-yet-unknown
attacks on curve25519. Since we're not likely to need it, we might as well
pair it with SHA512 as a backup against as-yet-unknown attacks on SHA256.

Implementors who support ssh-ed25519 will need to carry SHA512 code around
anyway, so the incremental code cost is trivial. The speed cost of a SHA512
hash instead of a SHA256 hash is minuscule.

> - If we're going to have text saying SHA-1 is begrudgingly acceptable for
> backwards compatibility, we can't simultaneously say that it is "NOT SECURE"
> in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a
> graceful transition away from SHA-1. We must in that case pursue an
> aggressive transition, including condemnation of existing products that use
> it.

I agree: saying SHA1 is "NOT SECURE" here is overdoing it a little. The
justification for abandoning SHA-1 on signatures is that these have a
relatively long lifetime during which they can be attacked - O(year).
Key exchange hashes have a much smaller temporal window for attack -
only as long as an implementation is willing to accept a client that
doesn't reply before NEWKEYS - O(minutes).

> - Niels has suggested that it's onerous to have so many "MUST" curves. We've
> already reduced the number of MUST curves from three (in RFC 5656) to two
> (in this draft). I'm not sure that either nistp384 or nistp521 are suitable
> candidates for demotion. However, if we make changes here, it seems we
> should keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to
> that nistp384 meets current longest-term guidelines; whereas nistp521 seems
> to be overkill, and slower.

AFAIK nistp521 is quite a bit faster than nistp384 in practice (OpenSSL)
because it's been optimised. ~nobody uses nistp384, so it hasn't.

$ openssl speed ecdh
[...]
Doing 256 bit  ecdh's for 10s: 45769 256-bit ECDH ops in 9.98s
Doing 384 bit  ecdh's for 10s: 10505 384-bit ECDH ops in 9.98s
Doing 521 bit  ecdh's for 10s: 13095 521-bit ECDH ops in 9.98

-d