Disabled brainpool curves

Anthony Scarpino anthony.scarpino at oracle.com
Tue Dec 13 17:58:21 UTC 2022


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.

Tony


On 12/13/22 5:34 AM, Sean Mullan wrote:
> 
> 
> On 12/13/22 2:39 AM, 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
>>>> 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



More information about the security-dev mailing list