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

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 <[email protected]> , 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