elliptic curves specification via JSON (neuromancer.sk)#346
Draft
thecyberfred wants to merge 10 commits into
Draft
elliptic curves specification via JSON (neuromancer.sk)#346thecyberfred wants to merge 10 commits into
thecyberfred wants to merge 10 commits into
Conversation
|
|
…ong correlations). also presenting alternative CMOV_ALTERNATIE with weak correlation
…CMOV closer to 0.99
…duce effect of cpu-speed-changes
3dcddf0 to
82e036e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
the website https://neuromancer.sk provides many elliptic curve standards with explicit parameters in JSON format and sagemath examples (just install+run sagemath, copy and paste - easy usage). the NIST page for example lists 15 standards, and provides a common JSON file, which specifies all in a signle file. and many further cathegories are available - all fulfilling a common JSON scheme.
at the moment, three NIST curves are specified in our kotlin code - this small list could be significantly extended, but major changes will be required. currently an enum is used in ECCurve, but it should be refactored to an interface. this however requires some decisions - in which order should we implement what? ECMath will require new code - how much is already there and where can we find the details for the remaining parts? how should we test?
one explicit test could be as following: since neuromancer provides sagemath examples, we could compare our results with the output from sage. this should be easy to implement as python/sage allowes simple wrappers from kotlin.
a major question might be on non-prime fields: at the moment we only support prime fields (F_p with p prime) but some curves might require binary fields (F_{2^k}) - or even more generally F_{p^k}, but not sure if those are used in practice. one approach would be to - for the begging - stick to prime field arithmetics and provide the corresponding curves. if all this is done (will be a lot of work), we could then in a second phase, generalize the code to general non-prime fields.