-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keybase: Multiple Signature Algorithms #5439
Conversation
27f4fe7
to
ae68ce9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It all makes sense and looks good. I'd just like to see two things being taken care of:
- Coverage
- CHANGELOG entry cause multiple API breaking changes are introduced
45070ea
to
48562f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @sunnya97. A lot of errors are not being checked. Also, the provided hdPath is not validated.
Nit, I personally don't like the term algo
as it means "something" in Spanish. Better use the full word algorithm
.
There was already a type called |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK. Will wait for @bez and @AdityaSripal review too before merging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look fine. I left some feedback, mainly questions 👍
@@ -112,6 +116,14 @@ func RunAddCmd(cmd *cobra.Command, args []string, kb keys.Keybase, inBuf *bufio. | |||
interactive := viper.GetBool(flagInteractive) | |||
showMnemonic := !viper.GetBool(flagNoBackup) | |||
|
|||
algo := keys.SigningAlgo(viper.GetString(flagKeyAlgo)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Secp256k1 is already the default. Why manually do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting Secp256k1
as the default wasn't working for me, something weird with cobra.
crypto/keys/keybase_base.go
Outdated
func baseSecpPrivKeyGen(bz [32]byte) tmcrypto.PrivKey { | ||
return secp256k1.PrivKeySecp256k1(bz) | ||
// StdPrivKeyGen generates a secp256k1 private key from the given bytes | ||
func StdPrivKeyGen(bz []byte, algo SigningAlgo) tmcrypto.PrivKey { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems...hacky. Why do we need this? For testing purposes only? The method name is not indicative of it only supporting secp256k1 keys. Can we at least expand it to support all other known key types too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, by default, I think we only want to support secp256k1, as that's what the current x/auth
module in the Cosmos SDK does. But I agree, it's probably a good ideas to add SecpPrivKeyGen
as separate function, and have StdPrivKeyGen
use it. That was when we add other keys as the Std defaults, we just add them to the Std
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I agree, it's probably a good idea to add SecpPrivKeyGen as a separate function, and have StdPrivKeyGen use it. That was when we add other keys as the Std defaults, we just add them to the Std function.
I see you've already done this! Nice. But I see no harm in supporting all the algos here. Also, we should return an error if the provided algo is not supported or recognized, so the caller doesn't blindly receive nil
in such a case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not want the standard default to be only supporting secp keys?
masterPriv, ch := hd.ComputeMastersFromSeed(seed) | ||
return hd.DerivePrivateKeyForPath(masterPriv, ch, fullHdPath) | ||
// StdDeriveKey derives and returns the secp256k1 private key for the given seed and HD path. | ||
func StdDeriveKey(mnemonic string, bip39Passphrase, hdPath string, algo SigningAlgo) ([]byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as StdPrivKeyGen. I'd recommend updating the godoc to be more general and support all known key types. There isn't even an error returned if the algo isn't SECP256K1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above.
crypto/keys/keybase_base.go
Outdated
func baseSecpPrivKeyGen(bz [32]byte) tmcrypto.PrivKey { | ||
return secp256k1.PrivKeySecp256k1(bz) | ||
// StdPrivKeyGen generates a secp256k1 private key from the given bytes | ||
func StdPrivKeyGen(bz []byte, algo SigningAlgo) tmcrypto.PrivKey { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I agree, it's probably a good idea to add SecpPrivKeyGen as a separate function, and have StdPrivKeyGen use it. That was when we add other keys as the Std defaults, we just add them to the Std function.
I see you've already done this! Nice. But I see no harm in supporting all the algos here. Also, we should return an error if the provided algo is not supported or recognized, so the caller doesn't blindly receive nil
in such a case.
masterPriv, ch := hd.ComputeMastersFromSeed(seed) | ||
return hd.DerivePrivateKeyForPath(masterPriv, ch, fullHdPath) | ||
// StdDeriveKey derives and returns the secp256k1 private key for the given seed and HD path. | ||
func StdDeriveKey(mnemonic string, bip39Passphrase, hdPath string, algo SigningAlgo) ([]byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes break keys stored in the current master
version of keybase requiring a keymigration. But being how we have yet to release v0.38 and users will have to migrate anyway, this may be moot.
Can you please confirm @alessio that users have to migrate all keys in their local keybase with the advent of v0.38 release?
On Mon, 13 Jan 2020, 23:06 Alexander Bezobchuk, ***@***.***> wrote:
Can you please confirm @alessio <https://github.com/alessio> that users
have to migrate all keys in their local keybase with the advent of v0.38
release
Yes, I confirm
… |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
testedACK
Codecov Report
@@ Coverage Diff @@
## master #5439 +/- ##
==========================================
+ Coverage 54.35% 54.36% +0.01%
==========================================
Files 313 313
Lines 18908 18908
==========================================
+ Hits 10277 10279 +2
+ Misses 7844 7842 -2
Partials 787 787
|
Description
This PR further modularizes the work started by @austinabell in #4941, in order to allow multiple signature algorithms to be supported by the same keybase. Required by #4789.
For contributor use:
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerFor admin use:
WIP
,R4R
,docs
, etc)