But X25519, X448, which are mark as safe in safecurves are protected against certain side-channel and other attacks, not only performance advantage.
 
07.06.2024, 22:33, "Hubert Kario" <hka...@redhat.com>:

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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to