Disabled brainpool curves

benjamin.marwell at f-i.de benjamin.marwell at f-i.de
Wed Dec 14 09:23:22 UTC 2022

Yes, I know that.

For the reasons I have given, I would like to request to remove brainpool 512 from that list for all users.
There is no good reason to disable that cipher on JDK 8. It is not insecure, that has been debunked by the BSI.

Any chance for this to happen?

- Ben

On 13.12.22, 18:58, "Anthony Scarpino" <anthony.scarpino at oracle.com <mailto:anthony.scarpino at oracle.com>> wrote:

# Externer Sender

Additionally JDK-8235540, was a java.security configuration change for 
JDK7 and JDK8. If you want to re-enable brainpool curves, change the 
java.disabled.namedCurves and/or 
jdk.[tls|certpath|jar].disabledAlgorithms properties in the java.security.

One policy won't fit everyone's needs, that's why this particular change 
was a configuration change only.


On 12/13/22 5:34 AM, Sean Mullan wrote:
> On 12/13/22 2:39 AM, benjamin.marwell at f-i.de <mailto:benjamin.marwell at f-i.de> wrote:
>> Hi everyone!
>> I just stumbled over “Disable weak named curves”, e.g.
>>https://bugs.openjdk.org/browse/JDK-8235540 <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 <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 <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 <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 <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 <https://mail.openjdk.org/pipermail/security-dev/2022-November/033428.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5591 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221214/5075dc6c/smime.p7s>

More information about the security-dev mailing list