-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
crypto: use SLIP10 for ed25519 key derivation for ts and cli #4524
Conversation
@@ -22,12 +22,16 @@ export function generateMnemonic(): string { | |||
} | |||
|
|||
/** | |||
* Derive public key and private key from the Mnemonics | |||
* Get public key and private key from the Mnemonics | |||
* @param mnemonics a 12-word seed phrase | |||
* @returns public key and private key | |||
*/ | |||
export function getKeypairFromMnemonics(mnemonics: string): Ed25519KeypairData { |
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.
we can try deprecate this method if the wallet team approves. we should always derive the key using SLIP-0010 (maybe with the default path to begin with)
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.
We're trying to move to a multi-account setup in the wallet in the future, so I'd be in favor of deprecating this method to start preparing for that.
@@ -31,9 +31,8 @@ fn mnemonic_test() { | |||
/// This test confirms rust's implementation of mnemonic is the same with the Sui Wallet | |||
#[test] | |||
fn sui_wallet_address_mnemonic_test() -> Result<(), anyhow::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.
in a follow up pr, this test can be merged with keytool_test (this test class can be deprecated)
import nacl from 'tweetnacl'; | ||
|
||
import type { Ed25519KeypairData } from '@mysten/sui.js'; | ||
import type { Ed25519KeypairData, Secp256k1KeypairData } from '@mysten/sui.js'; |
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.
the added the functions here is quite verbose to differentiate ed25519 vs secp256k1. this should really belong to the corresponding keypair file. will follow up a PR to move this class into sdk/typescript/cryptography
e27d506
to
c7457f2
Compare
💳 Wallet Extension has been built, you can download the packaged extension here: https://github.com/MystenLabs/sui/actions/runs/3079216656#artifacts |
47b32f2
to
6b404cc
Compare
@@ -478,6 +480,88 @@ where | |||
(kp.public().into(), kp) | |||
} | |||
|
|||
/// Ed25519 follows SLIP-0010 using hardened path: m/44'/784'/0'/0'/{index}' | |||
/// Secp256k1 follows BIP-32 using path where the first 3 levels are hardened: m/54'/784'/0'/0/{index} | |||
/// Note that the purpose for Secp256k1 is registered as 54, to differentiate from Ed25519 with purpose 44. |
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.
<3
/// Secp256k1 follows BIP-32 using path where the first 3 levels are hardened: m/54'/784'/0'/0/{index} | ||
/// Note that the purpose for Secp256k1 is registered as 54, to differentiate from Ed25519 with purpose 44. | ||
pub fn derive_key_pair_from_path( | ||
seed: &[u8], |
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.
In a future PR let's have the seed
as a distinct struct vs plain [u8]. Fine to merge as it is now; this will be a generic crypto refactoring.
crates/sui-types/src/crypto.rs
Outdated
// The derivation path must be hardened at all levels with purpose = 44, coin_type = 784 | ||
if let &[purpose, coin_type, account, change, address] = p.as_ref() { | ||
if purpose == ChildNumber::new(44, true).unwrap() | ||
&& coin_type == ChildNumber::new(784, true).unwrap() |
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.
I'd pin 784 and 44 as constants
crates/sui-types/src/crypto.rs
Outdated
Some(p) => { | ||
// The derivation path must be hardened at first 3 levels with purpose = 54, coin_type = 784 | ||
if let &[purpose, coin_type, account, change, address] = p.as_ref() { | ||
if purpose == ChildNumber::new(54, true).unwrap() |
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.
ditto for 54, pin as const
@@ -489,6 +494,106 @@ where | |||
(kp.public().into(), kp) | |||
} | |||
|
|||
/// Ed25519 follows SLIP-0010 using hardened path: m/44'/784'/0'/0'/{index}' | |||
/// Secp256k1 follows BIP-32 using path where the first 3 levels are hardened: m/54'/784'/0'/0/{index} | |||
/// Note that the purpose for Secp256k1 is registered as 54, to differentiate from Ed25519 with purpose 44. |
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.
👀 I don't quite agree to use 54 for Secp256k1 if we follow bip44.
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.
@5kbpers what do you suggest?
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.
@kchalkias IMO just using 44 is fine, otherwise some developers may be confused that we did not follow the standard.
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.
@5kbpers We need a way to distinguish between different key types. We realized other chains that support multiple schemes do that as well (usually for multi-sig), and we also picked 54 because there is no BIP54 (to avoid causing any confusion). Note that down the line Sui will support many key types and wallets should pick their favorite, but we need consistency on the deterministic derivation to allow for key (mnemonics) working with more than one vendors.
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.
Ed25519 uses purpose as 44 and it would be the recommended signing scheme.
we want to explicitly use a different derivation path for each signature scheme, and purpose level would be the most appropriate to use.
while it's non-standard to use purpose 54 for bip44, it's used by other currencies such as bitcoin to signify different signature schemes using purpose as something else (https://github.com/trezor/trezor-firmware/blob/master/docs/misc/coins-bip44-paths.md#notes ) also eth2 BLS validator key derivation. (https://eips.ethereum.org/EIPS/eip-2334)
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.
@joyqvq @kchalkias Thanks for your kind explanation! Understood what we were concerned about, now I think it looks good to me.
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.
Awesome job and design decisions (i.e., using 54 for the ECDSA k1 path).
In the future, I want us to explore further if the mnemonics deps should stay in this repo or fastcrypto
.
#4431
#4374
Ed25519 follows SLIP-0010 using hardened path with purpose = 44:
m/44'/784'/{account_index}'/{change_index}'/{address_index}'
Secp256k1 follows BIP-32 using path where the first 3 levels are hardened with purpose = 54:
m/54'/784'/{account_index}'/{change_index}/{address_index}
added test cases such that ts and cli are in parity for both schemes.
verified importing the generated phrase is the same