On Thursday, 6 June 2024 00:57:52 CEST, A A wrote:
"E.g. a client might also have legitimate reasons to nudge
servers to use a stronger curve than P-256 in the initial CH and
only fall back to weaker curves by explicit request via HRR.
Probably the reason for Chrome for requesting HRR for P-256 is
the attempt to nudge servers to use an algorithm which is
believed to provide advantages for the client-side
implementation (possibly both, speed/power or security or
bandwidth) in comparison to P-256."
About speed: https://bench.cr.yp.to/results-dh.html shows that
on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz;
hertz, supercop-20240425,
nistp256(P-256) needs 202616 cycles to generate a key pair,
535274 cycles to compute a shared secret;
Curve25519 needs 101289cycles to generate a key pair, 109491
cycles to compute a shared secret;
And, X25519's key share only need 32 bytes, P-256 needs 65
bytes. Conclusion: P-256 neither has security nor performance
(power) advantage compare with X25519.
That's not the performance delta I see in practice.
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
(run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself)
05.06.2024, 22:05, "Björn Haase"
<bjoern.haase=40endress....@dmarc.ietf.org>:
Hi Eric, Hi all,
One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change.
I think that we might rather keep a mechanism that preserves
the possibility of the client-side to express a preference
regarding a specific cipher suite / curve and accept other
curves only using the HRR-mechanism.
E.g. a client might also have legitimate reasons to nudge
servers to use a stronger curve than P-256 in the initial CH and
only fall back to weaker curves by explicit request via HRR.
Probably the reason for Chrome for requesting HRR for P-256 is
the attempt to nudge servers to use an algorithm which is
believed to provide advantages for the client-side
implementation (possibly both, speed/power or security or
bandwidth) in comparison to P-256.
Björn.
Mit freundlichen Grüßen | Best Regards
Dr. Björn Haase
Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Liquid Analysis
Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839
Gerlingen | Germany
Phone: +49 7156 209 10377
bjoern.ha...@endress.com | www.ehla.endress.com
Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.
Disclaimer:
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential,
proprietary, and/or privileged
material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon, this
information by persons or entities
other than the intended recipient is prohibited. If you receive
this in error, please contact the sender and delete the material
from any computer.
This e-mail does not constitute a contract offer, a contract
amendment, or an acceptance of a contract offer unless
explicitly and conspicuously designated or stated as such.
,
--
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
