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

wallet: disallow deriving ed25519 keys from default HD path #4272

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tzemanovic
Copy link
Member

Describe your changes

Follow-up to #4252. We disallow deriving ed25519 keys from the default HD path that's used for deriving shielded keys with the newly default modified ZIP32 to prevent accidental leak of these keys.

Checklist before merging

  • If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
    • This will require 2 reviewers to approve the changes
  • If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
    • Relevant PR if applies:
  • If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
    • Relevant PR if applies:

@tzemanovic tzemanovic requested a review from murisi January 24, 2025 17:21
@brentstone brentstone added this to the v1.1.0 milestone Jan 24, 2025
Copy link
Collaborator

@murisi murisi left a comment

Choose a reason for hiding this comment

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

Thanks! This will work. Just wanted to note two things that we have discussed already:

  • Users who derive a private key using namadaw gen --alias ..., note the displayed mnemonic, and use this mnemonic to derive a shielded spending/viewing key will end up in the undesirable state where both the seed and the derived shielded spending/viewing key are both stored in the software wallet. This situation is worse if the user did key generation using the flag --unsafe-dont-encrypt, since that would mean that the seed is stored unencrypted.
  • The functions Wallet::derive_store_hd_secret_key and Wallet::derive_store_key_from_mnemonic_code allow for the combined derivation and (potentially unencrypted) storage of modified ZIP 32 seed. So future changes to the codebase that make use of these functions might inadvertently bypass the checks made in this PR.

So while this PR blocks certain ways of reaching a state where a (potentially unencrypted) seed and its derivative shielded spending/viewing key are stored in the software wallet, there remain straightforward ways to enter this state from both the CLI and the internal APIs. And probably this situation is unavoidable due to the dual use of m/44'/877'/0'/0'/0' in namadaw gen's Ed25519 flow and also in the hardware wallet's modified ZIP 32 flow.

Copy link

codecov bot commented Jan 27, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.02%. Comparing base (80223b3) to head (260ad01).
Report is 13 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4272   +/-   ##
=======================================
  Coverage   74.02%   74.02%           
=======================================
  Files         345      345           
  Lines      109920   109920           
=======================================
+ Hits        81367    81371    +4     
+ Misses      28553    28549    -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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.

3 participants