More irony, X448, a ~224-bit security level curve, on Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; hertz, supercop-20240425, only needs 161176 cycles to generate a key pair, 530428 cycles to compute a shared secret, still faster than P-256, and it provide ~224-bit security level.


06.06.2024, 06:58, "A A" <tom25...@yandex.com>:
"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.


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.

 

,

_______________________________________________
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

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to