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

ed25519: use golang/x/crypto fork #2558

Merged
merged 5 commits into from
Oct 11, 2018
Merged

ed25519: use golang/x/crypto fork #2558

merged 5 commits into from
Oct 11, 2018

Conversation

ebuchman
Copy link
Contributor

@ebuchman ebuchman commented Oct 6, 2018

Closes #1959.

  • Remove some dead code (Curve25519 methods)
  • Assume ed25519 key always comes with pubkey (avoid need for MakePublicKey method)
  • Use golang.org/x/crypto
  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGELOG_PENDING.md

return PubKeyEd25519(pubkeyBytes)

if !initialized {
panic("pubkey bytes should always be initialized!")
Copy link
Contributor

@ValarDragon ValarDragon Oct 6, 2018

Choose a reason for hiding this comment

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

This may not be true with multi-language support for generating private keys. The pubkey in the private key is an optimization, but isn't "canonical" as far as what is described in the paper. I know dalek requires the pubkey to be inputted along with the private key when signing, so it wouldn't be included in marshalling.

I'm in favor of keeping the old code here though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So the only place we read in a priv key is the priv_validator.json and node_key.json. I think we can just make it a requirement that these come in the format that includes the pubkey? Then we don't have to worry here.

Think that's legit?

Copy link
Contributor

@ValarDragon ValarDragon Oct 6, 2018

Choose a reason for hiding this comment

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

Having the pubkey inside of the encoded private key for ed25519 is a design quirk they had to do due to the limited interface of cryptosystems within golang. I think we should support using the normal format as well. We will be reading ed25519 privkeys from gaiacli as well eventually, and I think its reasonable to expect more than just the sdk may be writing to gaiacli's privkeys?

Its not that big of a deal, so I guess we could just remove that support. (But then the error message should probably give a lot more detail, and will make it up to the user to debug this quirk)

@codecov-io
Copy link

codecov-io commented Oct 6, 2018

Codecov Report

Merging #2558 into develop will increase coverage by 0.15%.
The diff coverage is 60%.

@@             Coverage Diff             @@
##           develop    #2558      +/-   ##
===========================================
+ Coverage    61.29%   61.44%   +0.15%     
===========================================
  Files          203      203              
  Lines        16815    16759      -56     
===========================================
- Hits         10307    10298       -9     
+ Misses        5637     5587      -50     
- Partials       871      874       +3
Impacted Files Coverage Δ
crypto/xchacha20poly1305/xchachapoly.go 92.45% <ø> (ø) ⬆️
crypto/armor/armor.go 52.38% <ø> (ø) ⬆️
crypto/xsalsa20symmetric/symmetric.go 70.37% <ø> (ø) ⬆️
crypto/secp256k1/secp256k1.go 54.09% <ø> (ø) ⬆️
crypto/hash.go 100% <ø> (ø) ⬆️
p2p/conn/secret_connection.go 73.93% <ø> (ø) ⬆️
crypto/ed25519/ed25519.go 48.43% <60%> (+4.84%) ⬆️
consensus/reactor.go 71.61% <0%> (-0.78%) ⬇️
libs/db/remotedb/grpcdb/server.go 0% <0%> (ø) ⬆️

@@ -72,6 +72,11 @@
## Some repos dont have releases.
## Pin to revision

[[constraint]]
name = "golang.org/x/crypto"
Copy link
Contributor

@melekes melekes Oct 8, 2018

Choose a reason for hiding this comment

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

not a fan of aliasing dependencies. if I am a developer and I see an import "github.com/.../...", I usually go to github.com to check out the source code for that import. But here you get what you see concept is broken, so one had to be aware of the alias ??somehow??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok - would a comment everywhere we import this that it's actually an alias be sufficient?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep. Or we could indicate that it's a fork by appending fork or tendermint to name:tendermint.com/golang.org/x/crypto ||golang.tendermint.com/x/crypto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm - I like this idea but dep doesn't want to let me do it so long as these URLs don't exist. Any ideas? Or do we need to create the valid endpoint first?

Copy link
Contributor

Choose a reason for hiding this comment

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

I like this idea but dep doesn't want to let me do it so long as these URLs don't exist

did not know that! probably not worth the efforts short-term

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really get why we don't just import tendermint/crypto everywhere

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Golang forking voodoo. It breaks things like internal packages

Copy link
Contributor

Choose a reason for hiding this comment

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

ohh, ok this lgtm then

Copy link
Contributor

@ValarDragon ValarDragon left a comment

Choose a reason for hiding this comment

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

This looks good to me, though we may still want more clarification surrounding the name aliasing. (i.e. rational in the dep file perhaps, and changing the comment from // forked to github.com/tendermint/crypto to something perhaps like // code lies in the fork github.com/tendermint/crypto

@ebuchman
Copy link
Contributor Author

Ok, opened an issue for follow up: #2608

@ebuchman ebuchman merged commit feb08fa into develop Oct 11, 2018
@ebuchman ebuchman deleted the bucky/ed25519 branch October 11, 2018 14:02
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.

4 participants