Does X448 actually provide "a huge advantage" in security (practically speaking) over X25519?
On a classical computer, the best known attack against X25519 requires circa 2^126 point addition operations - that is generally accepted as being infeasible. Attacking X448 requires far more point addition operations - however, all that means is that it is also infeasble. On a Quantum Computer, an attack on X448 requires perhaps 5 times as many Quantum operations and 70% more Qubits than an attack on X25519. This is nice, but (given as we know little about the eventual cost of either Qubit operations or Qubits themselves) I cannot characterize it as "huge" - it may very well be the case that once we have a Quantum Computer that is large/reliable enough to attack X25519, it is only a minor effort to scale it upwards to attack X448. From: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Sent: Friday, June 7, 2024 11:52 AM To: Hubert Kario <hka...@redhat.com> Cc: D. J. Bernstein <d...@cr.yp.to>; tls@ietf.org Subject: [TLS]Re: Curve-popularity data? >so we should also remove X448, as it's much slower than X25519? That does not follow from what I said. I think the important metric is performance/security. P-256 does basically not have any benefits compared to X25519 (excepts a few bits of security more) but these are quite irrelevant compared to the huge advantages is implication security provided by X25519. I do think IETF should move to X448 instead of P-384 and P-521 for use cases wanting a higher security level than P-256/X25519. Cheers, John From: Hubert Kario <hka...@redhat.com<mailto:hka...@redhat.com>> Date: Friday, 7 June 2024 at 17:41 To: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: D. J. Bernstein <d...@cr.yp.to<mailto:d...@cr.yp.to>>, tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] Curve-popularity data? On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote: > Hubert Kario wrote: >>Such small differences in performance should absolutely have no effect on >>IETF selecting an algorithm or not. > > I completely disagree. As long as people argue that we need > symmetric rekeying and reuse of key share because the ephemeral > key exchange algorithms are slow, I think the performance > differences illustrated in this thread are a very strong > argument why IETF should chose one algorithm over another. > Symmetric rekeying and reuse of key shares lowers > confidentiality and privacy in the face of pervasive > surveillance. Also, I would not call the differences small at > all. so we should also remove X448, as it's much slower than X25519? please, be reasonable > Cheers, > John Preuß Mattsson > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7258&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844307272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4v8gMeGXJpoFSWo8JPxFfT6VvUJHbcSI2YGIoOVRsg0%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc7258> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7624&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844316386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=G7rhNxEuiHpI1Ts4lyNZ8i%2By1fPqNxwtrexW79rGkcs%3D&reserved=0<https://datatracker.ietf.org/doc/html/rfc7624> > > From: Hubert Kario <hka...@redhat.com<mailto:hka...@redhat.com>> > Date: Friday, 7 June 2024 at 16:36 > To: D. J. Bernstein <d...@cr.yp.to<mailto:d...@cr.yp.to>> > Cc: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> > Subject: [TLS]Re: Curve-popularity data? > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844322698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=R%2BIUGXdprzl1xXpwsVcF%2FA2vKHLo%2BGvI70IlPikxGEw%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24version.tar.gz&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844326797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=osEhWlP6INOLpdHjewNL%2F471%2F2Rmyc1KHAVyMYntbgE%3D&reserved=0<https://www.openssl.org/source/openssl-$version.tar.gz> >> tar -xzf >> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24version.tar.gz&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844330722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SPJEWsd6%2FcFBnZRxxck2FEY1pThr4%2Bj9H2CBOhZSfJQ%3D&reserved=0<http://www.openssl.org/source/openssl-$version.tar.gz> >> cd openssl-$version >> ./Configure --prefix=$HOME --openssldir=$HOME/ssl && make -j >> && make install >> ) >> ( wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frandombytes.cr.yp.to%2Flibrandombytes-latest-version.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844334552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EEQXgzEC13pSdPEWeSc9%2FrRJ%2BexMOOlOX8RcfQgBJAI%3D&reserved=0<https://randombytes.cr.yp.to/librandombytes-latest-version.txt> >> version=$(cat randombytes.cr.yp.to/librandombytes-latest-version.txt) >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frandombytes.cr.yp.to%2Flibrandombytes-%24version.tar.gz&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844338499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ES7n2zB7M%2FI%2FKBZ1BG3rXt57Te6u7irddbacjEkUZ0Q%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcpucycles.cr.yp.to%2Flibcpucycles-latest-version.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844342354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cBP4CCrEfqyf1INQwDuiqYpczC9mdEdY7LR%2Fn7T6ssY%3D&reserved=0<https://cpucycles.cr.yp.to/libcpucycles-latest-version.txt> >> version=$(cat cpucycles.cr.yp.to/libcpucycles-latest-version.txt) >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcpucycles.cr.yp.to%2Flibcpucycles-%24version.tar.gz&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844346028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=451GJczoMguRbhOg%2BFaJG%2FcXTyZyWINfeshC2k0c8CU%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flib25519.cr.yp.to%2Flib25519-latest-version.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844349773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Sjm%2F%2BkBYqE0mK6FryhLjIpvVMPEUky1nqmZdIrrE9%2BA%3D&reserved=0<https://lib25519.cr.yp.to/lib25519-latest-version.txt> >> version=$(cat lib25519.cr.yp.to/lib25519-latest-version.txt) >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flib25519.cr.yp.to%2Flib25519-%24version.tar.gz&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844353404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DUlu3cOFhyXfLX7M7m6NXAX5n7ExClof4lRUnTRVkB4%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2F2024%2F20240314%2Fopenssl_x25519_lib25519.c&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844357151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5VW9IvfX14GY68iEoCw9aJuyvt5k5%2Fne5Hw893RcKbY%3D&reserved=0<https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c> >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2F2024%2F20240314%2Fopenssl_ed25519_lib25519.c&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844360908%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CAV%2Bqvw4H00O1x1Agk9YwV6xN8%2B7BMRTTnjsckG31wg%3D&reserved=0<https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c> >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2F2024%2F20240314%2Fxtest&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844364624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=obyoOASbSLU9q4idZBWpDHG9uIUDNffo3I8bNte9SAo%3D&reserved=0<https://cr.yp.to/2024/20240314/xtest> >> wget -m >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2F2024%2F20240314%2Fedtest&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844369476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Xe8JoveRPl8nppA%2BtiSsPRUHZr16CwHL8MPBeCMJ2lM%3D&reserved=0<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: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844373926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IqPJDTgeL%2B9ivnmdv1x4KG412KFmrrSnaAiOq7ia2CA%3D&reserved=0<http://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
