crypto: move keys to sdk

[tac0turtle]

Description

• this is how I see moving keys to the cosmos-sdk
• this PR is just to show, there is still work that needs to be done

ref #5819

Signed-off-by: Marko Baricevic [email protected]

---

For contributor use:

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

---

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[alessio]

This is a very good start indeed! How about splitting the old keybase and the new keyring implementations into two separate packages crypto/keybase and crypro/keyring? So that we would potentially end up having separate New constructors, one in each implementation-specific package. This would also smooth the future deprecation of crypto/keybase.

[tac0turtle]

I will actually do that and the renaming of keys to keybase in a different pr so that people could easily review the key stuff in detail. this PR has ballooned 🎈

[tac0turtle]

closing this as discussed with @alexanderbez. The cosmos-sdk will define its own proto type for keys

[fedekunze]

How about splitting the old keybase and the new keyring implementations into two separate packages crypto/keybase and crypro/keyring? So that we would potentially end up having separate New constructors, one in each implementation-specific package. This would also smooth the future deprecation of crypto/keybase.

@alessio the keybase and keyring have a lot of common types that depend on each other. I'd just create a crypto/keyring directory to make the migration easier and avoid creating an extra /types or /common directory with the shared types.

[alessio]

@fedekunze sounds like a wise strategy 👍