Skip to content
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

Issue/350 #357

Closed
wants to merge 2 commits into from
Closed

Issue/350 #357

wants to merge 2 commits into from

Conversation

Despire
Copy link
Contributor

@Despire Despire commented Nov 9, 2019

This should fix the creation of signer with an invalid key type as described in #350 . I believe that ed25519 in the description was supposed to be secp256k1.

Also simplified nalc.Decryptor as it was doing an unnecessary second key validation in decryptor.Decrypt

if err := validatePrivateKeyType(privateKey); err != nil {
return nil, errors.WithStack(err)
}
return &Signer{privateKey: privateKey}, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return statements should not be cuddled if block has more than two lines (from wsl)

if pk, ok := e.privateKey.(*secp256k1.PrivateKey); ok {
prv, err = pk.ECDSA()
}
if pk, ok := e.privateKey.(secp256k1.PrivateKey); ok {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if statements should only be cuddled with assignments (from wsl)

}
return types.SignTx(opts.Tx, types.HomesteadSigner{}, ecdsa)
return types.SignTx(opts.Tx, types.HomesteadSigner{}, prv)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return statements should not be cuddled if block has more than two lines (from wsl)

Copy link
Member

@robdefeo robdefeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Despire for this PR 😄
Looks like you are actually fixing 2 issues #350 and #331 could you create a separate PR for #331 to make it clearer. That would be awesome as then its 2 PR's!!!!! 👍 👍 Thank you

wantErr bool
}{
{
"success-ed25519-sofia",
"success-ed25519-charlotte",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot!

false,
},
{
"err-secp256k1-sofia",
"err-secp256k1-charlotte",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot!

}

func validatePrivateKeyType(pk crypto.PrivateKey) ([]byte, error) {
switch pk := pk.(type) {
func validatePrivateKeyType(pk crypto.PrivateKey) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I your instinct to trying and simplify this. Let me give you a bit more information on why this method returns the []byte because its not clear from the code. pk.Bytes() returns the private key bytes, however this method has multiple uses (which is a bad thing!) its used for storing the private key in the keystore, decrypting and signing private keys. This needs to be resolved in the long term and I'll create an issue around that but there is a bit of investigation needed, I''ll raise it and would be great to get your comments. This method then is responsible for ensuring the key is of a valid type but also extracting the bytes that are relevant for decryption. If [32:] is moved when calling easyOpen you have then it is not aware of what type of key it is and it may pick the incorrect bytes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for the clarification

}

return easyOpen(data, privKeyBytes)
return easyOpen(data, d.privateKey.Bytes()[32:])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Different keys may have different ranges for returning the bytes to use when decrypting. If [32:] is done here you have then it is not aware of what type of key it is and it may pick the incorrect bytes.

@@ -31,8 +32,11 @@ type SignerOptions struct {
}

// NewSigner returns a new ethereum signer that can be used to sign transactions.
func NewSigner(privateKey crypto.PrivateKey) Signer {
return Signer{privateKey: privateKey}
func NewSigner(privateKey crypto.PrivateKey) (*Signer, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this file look out of scope for #350.
they appear related to #331 could you move them in to a seperate PR for that to make it clearer. That would be awesome as then its 2 PR's!!!!! 😄

@@ -26,7 +26,7 @@ import (
func Signer(protocol string, pk crypto.PrivateKey) (signer.Signer, error) {
switch protocol {
case protocols.Ethereum:
return ethereum.NewSigner(pk), nil
return ethereum.NewSigner(pk)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this file look out of scope for #350.
they appear related to #331 could you move them in to a seperate PR for that to make it clearer. That would be awesome as then its 2 PR's!!!!! 😄

Copy link
Contributor Author

@Despire Despire Nov 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback!
I'm a little bit confused with issues #350 and #331, they appear same to me, with the only difference being that in the description of #350 that the public key type needs to be ed25519 and in #331 secp256k1
Also the title of #350 says to ensure valid keys are used for nacl.Decrypter isn't that already done here ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the lack of clarity @Despire let me add a bit more information.

In the case of signing a transaction and decrypting a message the private key is required. The code that you are implementing is very similar with the main difference being using secp256k1 or ed25519.

No here is the part that's made it very confusing for which I am very sorry for! You are absolutely correct the link does make that issue redundant. I will instead open an issue for nacl.NewEncrypter() #359

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again thanks for the clarification 😄
I guess this PR can be closed along with issue #350.

@robdefeo
Copy link
Member

Closing this PR as some changes moved to #358 and issue #350 has already been resolved but was left open. Issue #350 also closed now.

@robdefeo robdefeo closed this Nov 10, 2019
@Despire Despire deleted the issue/350 branch November 22, 2019 19:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants