Getting private keys from a BIP 39 seed.

[gentlemand]

I'm trying to extract some private keys generated by a Trezor seed for XEM. It's out today but as far as I can tell there's no straightforward way I can derive a private key from this seed.

There's the Ian Coleman BIP 39 thing and its offshoots but they all have a specific list of coins and XEM isn't on any of them.

I'm clueless about this stuff so is there anyone who can tell me how you can do this if a coin isn't listed on one of these sites? Presumably it'll come back with a load of shite if the wrong coin is selected.

This is the derivation path on the Trezor - m/44'/43'/0'/0'/0'  . I have the seed. Beyond that I'm stumped.

Will I have to wait for the people who compile these things to add their extra magic before it works for this coin?

[1715700375]

1715700375

[achow101]

This is the derivation path on the Trezor - m/44'/43'/0'/0'/0'  . I have the seed. Beyond that I'm stumped.

Go to https://iancoleman.io/bip39/. Choose the BIP 32 tab. Enter that derivation path. You will then get the private keys.

[gentlemand]

XEM is not on the list of coins on that source. When I enter that and the seed all I get is more Bitcoin addresses and private keys. Same goes for anything else I select. It's coin dependent.

It must require some type of input of initial code from whichever coin to give you results back.

The person who created this on Trezor must have had a way to do it. I can't find anywhere in public.

[SopaXT]

Apparently, NEM private keys are in the conventional hexadecimal format.

You can use bitaddress.org (of course, you should be running it offline) -> Wallet Details, paste your bitcoin-format private key there, and scroll down to see the "Private Key Hexadecimal Format (64 characters [0-9A-F])" field.
These 64 hex digits should be the private key that can be used in NEM.

[achow101]

XEM is not on the list of coins on that source. When I enter that and the seed all I get is more Bitcoin addresses and private keys. Same goes for anything else I select. It's coin dependent.

It must require some type of input of initial code from whichever coin to give you results back.

It is only the encoding of the private key that is coin dependent. The private key itself is not coin dependent. You can decode the Bitcoin WIF private key into hexadecimal form, drop the extra encoding bytes, and just get the raw private key in hexadecimal. Then encode that with whatever coin encoding you want to use. Sites like bitaddress.org will do all of this decoding for you.

[gentlemand]

Holy moly. I think I need my hand held here. Thanks for everything so far.

So I've been fiddling around with the Ian Coleman thing. I can indeed get a private key that an XEM wallet recognises from the seed doing the bitaddress thing which is definitely progress, but it isn't recreating the original XEM address that the Trezor creates in the XEM wallet with this seed so evidently it's not deriving the same private key.

I'm entering the seed. I'm entering this derivation path in the BIP 32 tab - m/44'/43'/0'/0'/0' as the Trezor shows me.

I'm entering the private key on the first corresponding line delivered from the Ian Coleman tool marked m/44'/43'/0'/0'/0' into Bitaddress to get the hexidemcial key.

But it's not giving me the correct private key to match the Trezor XEM address when I create another XEM private key wallet. What might I be doing wrong? This could all be painfully obvious, but I never claimed not to be.

If anyone can be arsed I'll tip them.

Here's my junk Trezor seed -

mouse rapid remember click sample strong climb rain essence company board lumber blur return submit globe person rapid nominee pilot try boy truly phrase

Here's the address that seed creates with the Trezor in the XEM wallet - NCXL2T-RPKSH6-2EYJUX-5SPCRO-PBY3V5-L7HEBB-HY3Y

Here's the private hexidecimal key derived from the above method I've outlined - 94C63352FF1A933B227845237313E1217A0986222BBAE90325399DEE595EB1BF

And this is the address that key creates when I feed that hexidecimal key into an XEM wallet - ND6OF2-BA27YV-CGSMWF-M5LYGV-XUFAGY-I2EUJA-BWCE

[achow101]

Holy moly. I think I need my hand held here. Thanks for everything so far.

So I've been fiddling around with the Ian Coleman thing. I can indeed get a private key that an XEM wallet recognises from the seed doing the bitaddress thing which is definitely progress, but it isn't recreating the original XEM address that the Trezor creates in the XEM wallet with this seed so evidently it's not deriving the same private key.

I'm entering the seed. I'm entering this derivation path in the BIP 32 tab - m/44'/43'/0'/0'/0' as the Trezor shows me and I'm entering the private key on that corresponding line from the Ian Coleman tool into Bitaddress to get the hexidemcial key.

But it's not giving me the correct private key to match the Trezor XEM address when I create another XEM private key wallet. What might I be doing wrong? This could all be painfully obvious, but I never claimed not to be.

The XEM address may correspond to the compressed public key, but your private key corresponds to the uncompressed public key. The compression of a public key is simply set by an additional byte at the end of the public key. To try the compressed public key, add 01 to the end of the hex string that you have for the private key.

[gentlemand]

The XEM address may correspond to the compressed public key, but your private key corresponds to the uncompressed public key. The compression of a public key is simply set by an additional byte at the end of the public key. To try the compressed public key, add 01 to the end of the hex string that you have for the private key.

Thank you. Tried that. No dice.

I added 01 to the key above and it gives met a new and different address. Like I said I could be doing something very obviously wrong and wouldn't know.

[SopaXT]

Don't forget to reset your Trezor afterwards, since you've exposed your seed!

[SopaXT]

Well, I've kind of figured it out.
First of all, you have to set the derivation as m/44'/43'/0'/0' and check "Use hardened addresses" (since the last part is the account address and appended automatically).
Second, if you set the Coin to ETH, you'll get the raw hex private key (since Ethereum does not have an address encoding of its own).

The correct private key would be "0xe39f02b9a4c6a38d2082568dbfbea91c323a6a4da6f3cf0f876ade767d25ca33", but unfortunately, that does not produce a valid address.

Are you sure that you didn't use a password with your Trezor mnemonic?

[gentlemand]

Thanks for trying and yes it's a junk seed for pure testing. And no password was added.

Evidently there is something slightly different about XEM. I've read elsewhere that it uses SHA3 + RIPEMD160 whereas most other coins use secp256k1+RIPEMD160. That's gibberish to me but it means that site might need to specifically adjust something for it to produce valid results.

I asked Trezor themselves and they sent me to the Ian Coleman thing so if even they don't know that it's a tad worrying, but then again the whole point of Trezor is not needing to do it.

[SopaXT]

Thanks for trying and yes it's a junk seed for pure testing. And no password was added.

Evidently there is something slightly different about XEM. I've read elsewhere that it uses SHA3 + RIPEMD160 whereas most other coins use secp256k1+RIPEMD160. That's gibberish to me but it means that site might need to specifically adjust something for it to produce valid results.

I asked Trezor themselves and they sent me to the Ian Coleman thing so if even they don't know that it's a tad worrying, but then again the whole point of Trezor is not needing to do it.

Apparently, NEM uses a different curve for key derivation.
AFAIK, Ian Coleman's tool only supports BIP32 with secp256k1, which is not suitable for NEM.
NEM uses Ed25519, which is completely different.

[gentlemand]

That settles it then. I was suspecting as much. I've asked on the Ian Coleman github so perhaps he can do something with it.

Thanks again.

[SmilingFortune]

After long searching on the internet for the solution, I found this topic and finally my answer - a working tool to be used offline, at https://github.com/saleemrashid/nem-trezor-standalone Thank you gentlemand (!!!) for opening of this thread, for discussion here. Getting a tool allows us to have full control over our private keys for NEM, even when Trezor is broken or lost, not replaceable by another device. Our keys = our coins. Everything we need to know then, with the generator, is our seed and our password. It even allows us to download the wallet exported. There are generators for other coins out there but they are mostly using secp256k1 curve, instead of Ed25519 curve, used by NEM. Kudos to both  of you gentlemand and saleemrashid !!!