BIP39 and SLIP39 generated wallets do not match

[ksedgwic]

The LetheKit seedtool application generates new wallets using dice entropy to create BIP39 and SLIP39 recovery mnemonics. The BIP39 and SLIP39 mnemonics represent valid wallets, but they are not the same wallet.

This is a serious problem. If both BIP39 and SLIP39 backups are created at the same time and funds are placed in the BIP39 wallet the SLIP39 backup will fail to recover the same wallet and the funds would be lost.

Why is this the case?

Andrew Kozlik explains it well in this GitHub comment

How can matching BIP39 and SLIP39 backups be made?

Andrew Kozlik explains (above) that in principle, SLIP39 shares which are 59 words long could match a BIP39 mnemonic. In practice SLIP39 shares of this length are non-standard and unlikely to be supported by any devices or applications. The extreme length is also significantly painful to record and enter.

Impact on LetheKit/seedtool:

The desired feature of (standard) matching BIP39 and SLIP39 backups is not possible.

The conversion of a BIP39 backup into a SLIP39 backup is not possible.

The conversion of a SLIP39 backup into a BIP39 backup is not possible.

LetheKit/seedtool can generate valid BIP39 and SLIP39 wallets but should not allow generation of both at the same time or suggest it can convert between the two.

LetheKit can restore SLIP39 backups, but a mechanism to export the master secret (likely via QR code) would need to be added.

[ChristopherA]

My deal breaker here is that losing the ability to round trip from BIP39<->seed<->shards means that wallets are locked in to supporting SLIP39 the way Satoshi Labs does it. With our current sharding method (which will need to be changed to not confuse with SLIP39), you are not locked in to the Trezor — if a particular wallet does not support shards, you can convert the shards back into the seed, then back to BIP39 to the alternative wallet.

Our sharing method also supports binary mode, which allows use with QR codes the the UR: scheme, as well as allowing the addition of optional but often useful metadata like birthday, channel detail, etc. Satoshi Labs was very much against any additional data as it would increase the size of the mnemonics.

I was fine with supporting SLIP39 if there was no compromise on the round trip, and some how we missed this in our F2F discussion in Prague. (draft output at https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/shamir-secret-sharing.mediawiki and more notes at https://docs.google.com/document/d/1erTs0ybf02JbCznw25DYOEDfhIwP4TL53QAZydrzWmQ/edit#heading=h.imy5xgr88lxa )

If the community consensus is that SLIP39 is broadly committed to and supported enough to compromize round trip, I'll reluctantly support it but I'll need to tell everyone in #SmartCustody that it risks vendor-lock-in until other major vendors support it. In the meantime, we'll focus on the binary QR and sharding approaches https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-0005-ur.md

/cc @wolfmcnally @maaku @howech

-- Christopher Allen

[secinthenet]

@ChristopherA maybe you're already aware of it, but SLIP39 doesn't specify what secret you split. The doc only says "SSS splits a master secret, such as the master seed S for Hierarchical Deterministic Wallets described in BIP-0032". So, using the master seed S is the example given (and the implementation in Trezor as I understand it), but another option it to split the initial entropy in BIP39, making it possible to round trip between the two. That is, you can use the following scheme to make SLIP39 compatible:

SLIP39 shards <--> BIP39 entropy <--> BIP39 mnemonic

I'll also ask Trezor folks to verify.

[ksedgwic]

@secinthenet

SLIP39 shards <--> BIP39 entropy <--> BIP39 mnemonic

This is exactly what we do. But since you cannot restore to the same wallet on a SLIP39 device (ie Trezor) we call it "SSKR" instead.

[secinthenet]

@ksedgwic to confirm, you're using the exact same method with the exact same crypto, just on the BIP39 initial entropy (which can be converted to and from the mnemonic) instead of the BIP32 master seed? Which means for example that you can use bc-seedtool to encrypt a secret, and decrypt it with any SLIP39 library?

If that's indeed the case, it's good, because it makes it possible to reuse existing implementations of SLIP39. And I agree a different name is probably better to avoid

[andrewkozlik]

SLIP39 shards <--> BIP39 entropy <--> BIP39 mnemonic

This is exactly what we do. But since you cannot restore to the same wallet on a SLIP39 device (ie Trezor) we call it "SSKR" instead.

We would also advise using a different customization string for the RS1024 checksum to ensure that SSKR shares are not mistaken for SLIP39 shares, as noted in the Versioning section of SLIP39. The current specification uses the customization string "shamir", see Format of the share mnemonic.

[ksedgwic]

@ksedgwic to confirm, you're using the exact same method with the exact same crypto, just on the BIP39 initial entropy (which can be converted to and from the mnemonic) instead of the BIP32 master seed?

Yes, this is what is done.

Which means for example that you can use bc-seedtool to encrypt a secret, and decrypt it with any SLIP39 library?

The bc-seedtool-cli repo is a better place to ask, but I believe the answer is yes. We should explicitly test this before advertising it as a feature, of course.

[alandefreitas]

Hi @ksedgwic

I just happened to see this issue as we were discussing related issues in https://github.com/trezor/python-shamir-mnemonic/issues/40, and https://github.com/BlockchainCommons/seedtool-cli/issues/64. https://github.com/BlockchainCommons/seedtool-cli/issues/63 also discusses SLIP-0039 / BIP-0039 integration.

In our initial discussion in the SLIP-0039 reference implementation repository https://github.com/trezor/python-shamir-mnemonic/issues/40, we basically reach the conclusion that SLIP39 not supporting BIP39 was just a design choice. An unfortunate design choice in my opinion. I've forked the SLIP-0039 repo and implemented a prototype for BIP39/SLIP39 integration in alandefreitas/python-shamir-bip39.

I hope any of that is useful.

[aido]

@secinthenet

SLIP39 shards <--> BIP39 entropy <--> BIP39 mnemonic

This is exactly what we do. But since you cannot restore to the same wallet on a SLIP39 device (ie Trezor) we call it "SSKR" instead.

Hi,

Will SSKR be offered as a BIP? or maybe even added as an application to draft BIP-85?

[AnonymousAard]

Is there some way to use this to also store a BIP39 passphrase with the seedphrase?

[ChristopherA]

We are planning to work this summer on the ability to also do crypto-envelope with SSKR, which will allow additional information to be encrypted and sharded with the seed. This can be the BIP-38 passphrase, optional metadata like key birthday, name, or even things like descriptors or lightning channels.

However, this feature will make for larger URs, so are best for QR, not Bytewords on steel or titanium.

If you are a software engineer and want to help with this project (specs, coding, testing, or docs), we are starting the week of July 10th.

[mindrunner]

@ChristopherA Have you made any progress, yet? Do you still need developers? I would like to join :)

[ChristopherA]

@mindrunner We have the envelope version of SSKR available in the Test Flight beta of our reference app Gordian Seed Tool (see last weeks Gordian Developers Meeting, summary at https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions/114 and video on YouTube)

Are you still interested in helping out?

[mindrunner]

Generally interested. Limited in time due to work, tho. Let's have a sync and talk about the needs and how I could help out!