Hubert Kario writes:
> I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
> option?
Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line:
op op/s
256 bits ecdh (nistp256) 0.0001s 12184.0
253 bits ecdh (X25519) 0.0000s 24758.0
For comparison, results that I posted before without the option:
op op/s
256 bits ecdh (nistp256) 0.0001s 12186.0
253 bits ecdh (X25519) 0.0000s 24753.0
Doesn't look like the option has any effect on these numbers.
I checked the OpenSSL changelog, which says this option appeared in
3.2.0 to enable faster code for P-384, so I also tried "openssl speed
ecdhp384", and for that there's an obvious difference: 682.2 ops/sec
without the option, 1824.8 ops/sec with the option.
The changelog also says that this P-384 speedup is "using Solinas'
reduction". The OpenSSL P-256 code was already doing that, obviously.
> Yes, a good implementation of X25519 is faster than a good implementation
> of P-256. But it's not an orders of magnitude difference,
I agree that it isn't a 100x difference.
> and it ignores the whole case of there being dedicated silicon for
> P-256 arithmetic that makes such comparisons moot.
I presume you mean that those comparisons are moot specifically on
machines with P-256 hardware accelerators. Is there data on what
percentages of TLS clients and servers have those accelerators?
---D. J. Bernstein
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
