On 12/13/22 2:39 AM, benjamin.marw...@f-i.de wrote:
Hi everyone!
I just stumbled over “Disable weak named curves”, e.g.
• https://bugs.openjdk.org/browse/JDK-8235540
•
http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00/src/share/lib/security/java.security-aix.udiff.html
Interestingly, brainpoolP512r1 is on that list.
Just a few weeks ago I cited someone from the German BSI who debunked the myth
that brainpool ciphers are weak [1]].
They are only weak on TLSv1.3 if used not properly.
Please revert this change ASAP. It will break a lot of cryptography for no
reason.
Additionally, JDK-8235540 doesn't even mention how this list was chosen.
The reason for removing the brainpool curves was previously explained in
my post:
https://mail.openjdk.org/pipermail/security-dev/2022-November/033171.html
As I also said in that post, we would be open to reviewing contributions
from the community for reintroducing support for brainpool but they
would need to be done using the current design structure and using
complete formulas.
Thanks,
Sean
Here's the quote again from Manfred Lochter, how works at the BSI:
The unfortunate wording about the brainpool curves originated in TLS 1.3,
however RFC 8734 makes the curves usable for TLS again.
We will continue to recommend the Brainpool curves.
It should also be noted that the arguments for the "modern formulas" have all
been refuted by now.
Especially the implementation of Curve 25519 requires more effort to protect
against SCA;
the deterministic signatures are vulnerable to fault injection.
In the medium term, however, the switch to post-quantum cryptography is
necessary;
there are comprehensive recommendations on this at [2]
Please be aware that other users are already +1'd this [3].
- Ben
[1]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033108.html
[2]:
https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html
[3]: https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html
