RFR 8182999: SunEC throws ProviderException on invalid curves
Michael StJohns
mstjohns at comcast.net
Mon Jul 10 18:51:40 UTC 2017
On 7/10/2017 2:28 PM, Adam Petcher wrote:
> On 7/10/2017 1:55 PM, Michael StJohns wrote:
>
>>
>> What I'm mostly trying to get at here is to decouple or remove the
>> list of curves in ecdecode.c in favor of the list in the java stuff
>> (CurveDB.java) (or elsewhere). The C code should mostly only have
>> to deal with the math and not the housekeeping.
>>
>
> I agree that this would be a nice improvement, but I still think it is
> outside of scope of this fix. What you propose is a significant
> reorganization of the ECC code, and I don't think we should do that as
> part of a bug fix. It should be considered as a standalone refactoring
> effort, or maybe done as part of the next enhancement that adds
> support for new curves.
I'm not actually thinking this is an improvement rather than fixing an
incomplete or badly structured implementation, but I take your point. I
also don't think it's much of a reorganization - again - rather removing
an interdependency that shouldn't be there rather than papering over it
with an explanatory error. (Hmm.. have you checked to make sure that
the list of curves in ecdecode is a subset of the curves in CurveDB - if
not you may still have another problem).
I'd submit changes myself, but I don't currently have a good build
environment to test against.
WRT to new curves - the next effort will probably involve changes to the
public API to deal with the Curve25519 et al implementations. I'm not
sure any of the old curve stuff will get any attention at that point.
Thanks- Mike
>
>> Mike
>>
>>
>
More information about the security-dev
mailing list