crypto: provide simple way to add new curves #2424
Assignees
Labels
crypto
Cryptography-related
enhancement
New feature or request
needs-triage
This issue/PR has not yet been triaged by the team.
Milestone
Comments
|
to add on it would be nice to have the file system privval also take arbitrary curves. This way users dont also have to fork privval file once pluggable curves land relevant tendermint/tendermint#5603 but allowing the node instanciator to set the underlying curve would be one step better than the issue linked |
|
I think we would need a method such as Now one can implement the |
|
i think the pubkey proto type may need some changing as the current design wouldnt allow register key without redoing the proto types |
|
refs #2399 |
20 tasks
4 tasks
4 tasks
melekes
added a commit
that referenced
this issue
Jun 12, 2024
4 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 6, 2024
… and thread it through the code (#3517) Contributes to #2424 Precondition for #2534 This PR is inspired in the core idea of #2539, by @tac0turtle, whereby we make `privval` more flexible to generate privval files in all the curves we support in CometBFT natively. The flag `key-type`, which was only part of command `gen-validator`before this PR, is now part of all commands that _may_ generate priv validator keys (`start`, `unsafe-reset-all`, `unsafe-reset-priv-validator`, `init`). Importantly, node key, and node key file generation is still hard-coded to `ed25519` (no need to change it for the time being). Still TODO: * Add unit tests at various places to test the different key types --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
mergify bot
pushed a commit
that referenced
this issue
Aug 6, 2024
… and thread it through the code (#3517) Contributes to #2424 Precondition for #2534 This PR is inspired in the core idea of #2539, by @tac0turtle, whereby we make `privval` more flexible to generate privval files in all the curves we support in CometBFT natively. The flag `key-type`, which was only part of command `gen-validator`before this PR, is now part of all commands that _may_ generate priv validator keys (`start`, `unsafe-reset-all`, `unsafe-reset-priv-validator`, `init`). Importantly, node key, and node key file generation is still hard-coded to `ed25519` (no need to change it for the time being). Still TODO: * Add unit tests at various places to test the different key types --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com> (cherry picked from commit bd06fec) # Conflicts: # cmd/cometbft/commands/gen_validator.go # node/errors.go # node/node_test.go # privval/file.go
4 tasks
melekes
added a commit
that referenced
this issue
Aug 6, 2024
… and thread it through the code (backport #3517) (#3630) Contributes to #2424 Precondition for #2534 This PR is inspired in the core idea of #2539, by @tac0turtle, whereby we make `privval` more flexible to generate privval files in all the curves we support in CometBFT natively. The flag `key-type`, which was only part of command `gen-validator`before this PR, is now part of all commands that _may_ generate priv validator keys (`start`, `unsafe-reset-all`, `unsafe-reset-priv-validator`, `init`). Importantly, node key, and node key file generation is still hard-coded to `ed25519` (no need to change it for the time being). Still TODO: * Add unit tests at various places to test the different key types --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request #3517 done by [Mergify](https://mergify.com). --------- Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Feature Request
Summary
currently there is not a way to add new curves to comet unless you fork the software. This causes many forks for simple changes.
Problem Definition
adding new curves forces users to fork the software. (unless im missing something)
Proposal
add simple way to add new curves to be used for consensus key signing
Zondax is proposing an api to help with this in the sdk. we could look at hosting the new api in its own module to enable usage in comet as well
The text was updated successfully, but these errors were encountered: