Re: Understanding elliptic curve spec limitations

[Bernd Eckenfels]

This should also answer your other Question, if you Register a Provider (like bouncycastle) it should actually provide such curves via the JCE interface. I am not Aware of Bugs in this area (but on the other Hand besides some stupid EA-agency requirements for brainpool curves nobody in their Right mind uses esoteric curves in commercial Settings anyway). Having said that, a security product which „implementes all curves openssl supports“ might not be very secure after all… 😊   Gruss Bernd -- https://bernd.eckenfels.net   Von: David Blevins Gesendet: Dienstag, 28. September 2021 17:34 An: Anthony Scarpino Cc: security-dev@openjdk.java.net Betreff: Re: Understanding elliptic curve spec limitations   > On Sep 28, 2021, at 12:49 AM, David Blevins <dblev...@tomitribe.com> wrote: > >> On Sep 27, 2021, at 3:32 PM, Anthony Scarpino <anthony.scarp...@oracle.com> wrote: >> >> On 9/27/21 2:22 PM, David Blevins wrote: >>> I've been putting a significant amount of work into compiling a large set of elliptic curve parameters/names/oids for an open source library and a related closed source security product we have.  We need to be able to support any of the curves that OpenSSL/LibreSSL support. >>> The trick is this is currently impossible due to hardcoding in OpenJDK 16.  Though you supply valid parameters via ECParameterSpec, when you attempt to construct an instance of ECPrivateKey or ECPublicKey you hit code in sun.security.util.CurveDB that does a "reverse lookup" of sorts to find the curve name.  If it's not a curve CurveDB knows about, you can't use it. >>> Is there willingness to accept contributions that would remove this limitation? >> >> We haven't heard such issues since native obsolete curves were removed from 16.  We are will to take contributions upon review.  If you're going to formally contribute the code, you should check out https://openjdk.java.net/contribute/ > > Thanks, Tony. > > It also appears that of the 60 curves supported only 3 of them can be used to sign/verify.  Any insight as to why?   Found my own answer on this second question.   - https://bugs.openjdk.java.net/browse/JDK-8251547     -David