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
