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