search

iancoleman / shamir39

Split BIP39 mnemonics using Shamir's Secret Sharing Scheme
https://iancoleman.github.io/shamir39/
MIT License
187 stars 91 forks source link

Feedback about common shamir usage with bip39 (via ssss-split) #10

Open iancoleman opened 5 years ago

iancoleman commented 5 years ago

See https://github.com/iancoleman/bip39/issues/257#issuecomment-433740985

many popular wallets want you to back up your recovery seed using BIP39 mnemonics. If you can convert that string back into a 32 byte hex value, then you can run your seed through ssss-split -x -s 256 and get 32-byte hex shares. Each of those shares can itself be encoded using BIP39, which is much more user-friendly than writing down 64-128 hex digits.

hatgit commented 5 years ago

[Update: I just now saw this [https://github.com/satoshilabs/slips/blob/master/slip-0039.md] based on your proposal [https://github.com/iancoleman/shamir39/blob/master/specification.md] so the below post might not be relevant, not sure]

Could you provide an example of what data and format of the data the user would paste into SSSS and what parameters would need to be set in the SSSS tool, would it be 2 of 3? And then how could those shares be used (would you divide it into groups such as 256/4) depending on the mnemonic length needed? It seems like this would allow one to have multiple sub-mnemonics tied to a master one, is that a fair description?

For example, with the 2 of 3 share in SSSS, the following random 0x-padded hex string, '0xbaa32a03a66127dfdea9a58b3f6fdf20' produces three shares, each of which are 259 characters long, or 256 excluding the index (801,802,803):

801f5153185fb4693379011569b4eb9ebca4320e20a67f33077c1198721302c86ffa26a3215ec64f81a5e496ec4f221bdca71f5d86cacd0e50ee3dd6ecd52a46256d011ccb3804ff077c4689153199fe49839a36ae64bb82ff2034f8037850a268ccc8651b69ed781a1ecd1afc23fd9b8c759fe8b53b9a72ca90d468e5ed4544a3d

802f72a6217eb8c3b6e3d22ac2b9c6fcb898640d914cefb60ee9f321342605811e359d4642ac5c8ed34bc92dc95f9426789e2f7add845bdd71cdba7dc84a405c4fabd8885d71d34fdb4957a3ff33285d5657204d47296265e5a06311dc217be4ca98548a22721e01f05c5e5433a7efa6dc3b2420bf06f0658ec1a2f011ab520942a

803023f539210caa859ad33fab0d2d62043c5603b1ea90850995e2b94635074971cfbbe563f29ac152ee2dbb2510b63da43930275b4e96d3212387ab248f691a69e6dff49009d1d0df55174ae932b7831c54b92bef5dda771c9051b9d9192d26a4149f9f3a3bf069e922902ec994110d534ebdd8091d692742417088f26610cde27

Using just the first share (index 801) as variable a. slicing the following 4 groups of 64 hex strings can be extracted:

'>>> print('1: ',a[:64],'2: ',a[64:128],'3: ',a[128:192],'4: ',a[192:256])'

1: f5153185fb4693379011569b4eb9ebca4320e20a67f33077c1198721302c86ff 2: a26a3215ec64f81a5e496ec4f221bdca71f5d86cacd0e50ee3dd6ecd52a46256 3: d011ccb3804ff077c4689153199fe49839a36ae64bb82ff2034f8037850a268c 4: cc8651b69ed781a1ecd1afc23fd9b8c759fe8b53b9a72ca90d468e5ed4544a3d

Where each of the 4 extracted 64 hex strings becomes the pre-image (psuedo-entropy) to a 24-word mnemonic. Is this what you had in mind or did I take this in a different direction?

hatgit commented 5 years ago

Ignoring my above post, I think it is a fantastic idea to use mnemonics instead of having to write down the ciphertext/key that SSSS produces with each share. If that endeavor is still being pursued, or via SLIP0039, I have some ideas.

iancoleman commented 5 years ago

Yes I think slip-0039 will be the preferred method into the future. The authors are interested in feedback on the section Master secret derivation functions so if you have any thoughts I'm sure they'd be glad to hear via their repo.

I'm a little busy to respond to your post just now but will have a look at it when I get a chance.