8237219: Disabling the native SunEC implementation
Anthony Scarpino
anthony.scarpino at oracle.com
Wed Mar 4 02:49:11 UTC 2020
I think you are right for key generation that some addition to the
supported curve method will needed. With changing some of the
exceptions types I'm realizing that the native library was being used
more than I thought.
Tony
On 3/3/20 10:42 AM, Anthony Scarpino wrote:
> Yes, the exceptions are thrown in the same location because we need the
> init() and setParameters() set before we can decide if the curve is
> supported.
>
> The current java implementation falls through to the native code if the
> java code does not support there curve. I don't think we need any
> further methods.
>
> Tony
>
> On 3/2/20 7:09 PM, Weijun Wang wrote:
>> When the native impl is disabled, and an unsupported curve is used in
>> key pair generation, ECDSA, or ECDH, when will the exception be
>> thrown? Is it at the same place when native impl is enabled? I mean,
>> do we need some sort of java isSupported()?
>>
>> SecurityTools.java:
>>
>> If native is disabled, will many tests fail? Is it possible to modify
>> the tests? This is a helper method used by many tests and I'd rather
>> it uses the default setting.
>>
>> Thanks,
>> Max
>>
>>> On Mar 3, 2020, at 8:40 AM, Anthony Scarpino
>>> <anthony.scarpino at oracle.com> wrote:
>>>
>>> Hi
>>>
>>> I need a review of the CSR and webrev for disabling by default the
>>> native SunEC curves from the API. With the recent verification
>>> changes in JDK-8237218, SunJCE is long dependent on the native code
>>> for verifying the constant-time curves. This disabling can be undone
>>> with setting a system property, jdk.sunec.disableNative. I'm doing
>>> a simultaneous review as changes for one will likely affect the other.
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911
>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/
>>>
>>> The curves affected are:
>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1,
>>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1,
>>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
>>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1,
>>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1,
>>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62
>>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
>>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62
>>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1
>>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
>>>
>>> Tony
>>
>
More information about the security-dev
mailing list