jcalfee
commented
6 years ago fyi: Some work on the signatures has been done. Xeroc had a un-merged patch for Trezor and Bitshares the HW wallet that produced passing signatures. I don't see the patch now. But I do see a new xeroc PR for steem: https://github.com/trezor/trezor-mcu/pull/121
For BIP44, EOS is different. It does not have change addresses. Change addresses in BIP44 are fine but for contract permissions that are not a good fit. Due to the elliptic curve math derived keys on the same hierarchical level have a weaker security profile that make them unsafe. For example, one private key and a chain code can revile all private keys at that level and lower levels. So, this is better suited for flat and redundant change addresses but not suited for more meaningful contract permissions.
Deriving keys are done in binary and use only sha256 hashing that does not involve any elliptic curve math. So, while EOS needs something different it is actually easier to implement and understand.
This will be the starting point:
mnemonicSeedBuffer = bip39.mnemonicToSeed(mnemonic, passphrase)// new stuff I propose (this needs peer review):
chainCode = Buffer.from('00'.repeat(32), hex) // testnet is '00'.repeat(32), replace with real chainCode
MASTER_SALT = chainCode
chainSeedBuffer = createHmac('sha256', MASTER_SALT).update(mnemonicSeedBuffer).digest()
// Here is what we have implemented now for the front-end and endorsed by @bytemaster back in 2017..
// This is more standard and implemented in https://github.com/eosio/eosjs-keygen
owner = createHash('sha256').update(chainSeedBuffer).update('owner').digest() // root of everything
active = createHash('sha256').update(owner).update('active').digest() // active always under owner
custom1 = createHash('sha256').update(active).update('custom1').digest() //custom permissions are always under active
custom2 = createHash('sha256').update(active).update('custom2').digest() // custom permissions can be flat
custom2a = = createHash('sha256').update(custom2).update('custom2a').digest() // or nested
// the numbering in the custom variable name is just for illustrationIf you go digging into eosjs-keygen, you'll find unit test and up-to-date markdown docks illustrating and enforcing the rules I showed above. If you wish to make it compatible, the string from of the master key has a two letter prefix "PW" followed by a WIF key; the prefix is just cosmetic and can be removed and will play no role in hashing or deriving keys. So, for a given mnemonic and passphrase you could create the PW prefixed master key used to derive the same chainSeedBuffer data and the same derived keys (the mnemonic comes first then a compatible master password could be create). This use case is limited though because the master password is typically not cold storage but the mnemonic is.
https://github.com/EOSIO/eosjs-keygen
# See generateMasterKeys - https://github.com/EOSIO/eosjs-keygen/blob/v1.3.1/src/keygen.js#L34-L59
master = PrivateKey.fromSeed('test') // <- returns eosjs-ecc key_private.js
ownerPrivate = master.getChildKey('owner')
activePrivate = ownerPrivate.getChildKey('active')
customPrivate = activePrivate.getChildKey('custom') // custom contract permissionsIn getChildKey, I did leave a warning until I see it used in the eosio wallet:
function getChildKey(name) {
// console.error('WARNING: getChildKey untested against eosd'); // no eosd impl yet
const index = createHash('sha256').update(toBuffer()).update(name).digest()
return PrivateKey(index)
}
seitau
crazybits
c1pca
shikhars371
I would like to know the correct derivation path in order to derive EOS keys from mnemonic phrases. Now I am referring to SatoshiLab's list of coin types for BIP44. Please let me know if it is wrong.