On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
Hubert Kario writes:
Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s
The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from current code, I tried the script below on a Comet Lake (Intel Core
i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
for lib25519. The script prints results without and with the provider.
The results with the provider are a better predictor of the user's
ultimate costs than obsolete code; consider, e.g., AWS announcing in
https://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf
that they had already switched their deployments to the fast formally
verified X25519 code in s2n-bignum (which lib25519 supports internally).
The script's results using the provider are as follows:
op op/s
256 bits ecdh (nistp256) 0.0001s 12186.0
253 bits ecdh (X25519) 0.0000s 24753.0
sign verify sign/s verify/s
256 bits ecdsa (nistp256) 0.0000s 0.0001s 27569.0 9169.0
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0000s 66099.0 20126.0
Without the provider, X25519 gives 146% the operations/second of P-256
(close to the 154% you saw) rather than 203%. Also, OpenSSL has only
unoptimized code for Ed25519 and manages to be even slower than ECDSA;
obviously this is a reflection of Ed25519 not being allowed yet in
certificates rather than of the performance users will see.
Earlier I had also posted a similar script, posted Zen 2 results, and
mentioned that OpenSSL's built-in code cheats by not measuring various
key-expansion steps, whereas lib25519 never cheats. The difference in
this script is the part downloading and compiling OpenSSL 3.2.2.
I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
option?
But in general, I think this discussion of off-topic.
Yes, a good implementation of X25519 is faster than a good implementation
of P-256. But it's not an orders of magnitude difference, and it ignores
the whole case of there being dedicated silicon for P-256 arithmetic that
makes such comparisons moot.
Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.
---D. J. Bernstein
#!/bin/sh
export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export CPATH="$HOME/include"
export PATH="$HOME/bin:$PATH"
( version=3.2.2
wget -m https://www.openssl.org/source/openssl-$version.tar.gz
tar -xzf www.openssl.org/source/openssl-$version.tar.gz
cd openssl-$version
./Configure --prefix=$HOME --openssldir=$HOME/ssl && make -j
&& make install
)
( wget -m https://randombytes.cr.yp.to/librandombytes-latest-version.txt
version=$(cat randombytes.cr.yp.to/librandombytes-latest-version.txt)
wget -m https://randombytes.cr.yp.to/librandombytes-$version.tar.gz
tar -xzf randombytes.cr.yp.to/librandombytes-$version.tar.gz
cd librandombytes-$version
./configure --prefix=$HOME && make -j install
)
( wget -m https://cpucycles.cr.yp.to/libcpucycles-latest-version.txt
version=$(cat cpucycles.cr.yp.to/libcpucycles-latest-version.txt)
wget -m https://cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
tar -xzf cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
cd libcpucycles-$version
./configure --prefix=$HOME && make -j install
)
( wget -m https://lib25519.cr.yp.to/lib25519-latest-version.txt
version=$(cat lib25519.cr.yp.to/lib25519-latest-version.txt)
wget -m https://lib25519.cr.yp.to/lib25519-$version.tar.gz
tar -xzf lib25519.cr.yp.to/lib25519-$version.tar.gz
cd lib25519-$version
./use-s2n-bignum
./configure --prefix=$HOME && make -j install
)
( wget -m https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c
wget -m https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c
wget -m https://cr.yp.to/2024/20240314/xtest
wget -m https://cr.yp.to/2024/20240314/edtest
cd cr.yp.to/2024/20240314
sh xtest
sh edtest
)
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
