SSSS instead of seed cutting

[MaxHillebrand]

Context

In the chapter on Redundant Metal Devices you suggest to cut up the mnemonic in three parts, each containing two thirds of the mnemonic words.

Problem with current approach

Don't roll your own crypto. Afaik, this is not best practice. The full 24 word seed has 256bit entropy, so each third of the seed has roughly 85bits.[?] If the attacker compromises two thirds of the seed from one backup, he only needs to brute force the last third with comparatively very little effort.

Possible solution

How about a reference to Satoshilabs SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes?

[JayOceans]

hey Max, best practices are obviously still under-development...

regarding, your comment, "comparatively very little effort" is misleading, because it Would take a lot of effort to brute force 85bits... that's the same bad argument Andreas made about, "256 is soo much better than 128"...

dear authors, -- please, also consider -- split 24--> into 12 & 12

here's my seed-splitting protocol [CWAP] https://medium.com/@summerstarlight321/counter-wrench-attacks-83c75bfbb3de

here, I propose basic tenants & dissect arguments-- "seed-splitting standards" https://medium.com/@summerstarlight321/seed-splitting-standards-4ca9efbc03e3

also, i use [pass-phrases] to designate [ heir's wallets ] in my Inheritance method https://medium.com/@summerstarlight321/bitcoin-inheritance-protocol-5fb1e68b5509

thanks so much !!! very important work ! it's been my focus for over 1 year

i wrote 13 related articles here -- https://medium.com/@summerstarlight321 would love your critiques!...

[ChristopherA]

@MaxHillebrand We do discuss the limitations of this approach in the footnote:

[^25] Note that there is some danger if an adversary accesses one of your three metal-devices. Whereas the 24 words gives you 256 bits of entropy, if an adversary knew 16 words but not the remaining 8, you'd drop down to 80 bits of entropy. This is still relatively safe given the state of modern computers, but is far below the recommended entropy for protecting cryptocurrency long-term. If you lost one of your three metal devices, you should immediately reset your master seed and transfer your currency.

Basically right now 80 bits with good entropy is beyond current brute-force capabilities. We'll need to re-evaluate this recommendation over time — it may be that in 5 to 10 years, we will not recommend this practice at all. But in the meantime, it doesn't need a computer to re-construct the master seed, which is one of the key problems with other Social Key Recovery techniques like Shamir.

[ChristopherA]

@MaxHillebrand We are involved in the SLIP-0038 discussions, and met with a number of Social Key Recovery engineers & cryptographers at #RebootingWebOfTrust in early March. During the event we started a VERY early draft of Shamir Secret Sharing Best Practices:

https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/shamir-secret-sharing-best-practices.md

Our discussions include choice of finite field, multi-level "circle" Shamir ideas, nonce issues, unsolved problems, etc. Wolf demonstrated some interesting UX/UI prototypes for use on mobile (video coming soon), and HTC demonstrated their social key recovery for the new HTC Zion wallet on the Exodus cell phone. We also came way with some improvements that we'd like to see in Daan Sprenkel's SSS library, and some suggestions for improvements to the SLIP-0039 proposal:

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

In the last few weeks, SLIP-0039 has been updated to include the two-level Shamir originally proposed by Mark Friedenbach and I at:

https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/social-key-recovery.md.

Andrew Kozlik has added this functionality the the Python reference implementation of SLIP-0039 at:

https://github.com/trezor/python-shamir-mnemonic/

The current plan is to fork of Daan Sprenkel's SSS library to support both our cryptographic recommendations from #RebootingWebOfTrust, as well as the two-level Shamir that is now part of SLIP-0039. This will be hosted here in Blockchain Commons community at:

https://github.com/BlockchainCommons/sss

We also need to write up some cryptographic papers to submit for acadamic peer review, and possibly submit a draft of our cryptographic formats as an IETF-IACR standard specification.

Even though we hope to incorporate SSS approaches into future #SmartCustody best practices, we can't include in the short term until there has been a) cryptographic review of the new SLIP-0039 approach b) multiple implementations c) code security review of the various implementations, and d) some level of pragmatic maturity of its use by the industry.

[ChristopherA]

@JayOceans I appreciate your comment and links.

We are not confident about 12+12 splits, as they do not allow for any redundancy. This makes you more vulnerable to the Casual Theft and Denial of Access adversaries. You have not only protect multiple places, your attacker can choose your weakest place. However, as you suggest, give 12 words to many friends there may be a place for it if you are at risk to Coercion and other adversaries of force, and it also requires that those same friends are not coerced themselves, nor are coerced by the threat of your coercion (aka maybe "don't give shares to too good of friends"). I'm more willing to add this idea to the Adversary case studies when that document comes out this Q2, rather than to a basic document.

We also have not yet found sufficiently strong procedures using BIP-0038 encrypted recovery phrases. Other than Bitrot and Custodial Loss, in our informal survey of digital currency holders and developers have lost the most to loosing or insufficiently checking the BIP-0038 encrypted recovery phrase. If effect, you've just move the problem from one secret to another that you need to keep secret. I'm not saying that BIP-0038 is bad, just that if not used carefully and judiciously it typically makes procedures much less resilient.

I've not read through all of your links, but if there is another specific suggestion in this area that I missed, I welcome you adding it to this issue.

[shannona]

It's also important to note that splitting your keys into three 16-word sets is an alternative to having all 24 of your words in the same place. We suggest it primarily as a solution for the risk of Theft, particularly internal or institutional theft.

Yes, 80 bits is less than 256 bits, and as Christopher noted, we suggest immediately changing your master seed if you lose one of your metal devices. But, it's more than 0 bits, which is the actual alternative, and in that case your digital assets would already be gone as soon as you lost that device.

[JayOceans]

dear @ChristopherA & @shannona , thanks so much for your thoughtful replies !

just to clarify-

, as they do not allow for any redundancy.

i make many copies of each 12-word set and they're geographically separate --> which seems very redundant to me...

This makes you more vulnerable to the Casual Theft and Denial of Access adversaries.

since there is no single-point-of-failure, since there's no location with all access information, --> I don't see any possibility for Casual Theft... // that was the whole reason i created CWAP : P

and regarding Denial of Access, maybe, if they compromised all your redundant copies,... but, that's better than being a single-point-of-failure, where they would just Casual Theft it...

You have [to] not only protect multiple places, your attacker can choose your weakest place.

didn't quite follow that... but yes, my set-up is vulnerable if 2 geographically-separate attacks are successful...

and it also requires that those same friends are not coerced themselves,

as each of my Signatories only holds 12-of-24 words, all, but one of them, could be coerced with no lose of funds...

nor are coerced by the threat of your coercion

aka- a Ransom scenario, where the hostage held & gave up 12 words... as there are no solutions for this attack-vector presently, i only set up my storage, so as to NOT incentive a loved-ones kidnapping i'd much rather Kidnappers target me! // my article regarding this - https://medium.com/@summerstarlight321/attack-vectors-for-your-multi-sig-set-up-c6d024e192c3

aka maybe "don't give shares to too good of friends"

i don't quite follow this, sorry are you talking about the threat of a Signatory coming after you?... because they have 1/2, all they need is your 1/2 and if they're very good friends, maybe you see them often, or they know where you are...

if so, i do address this as "travel collisions" where, to defend, you would need to - restore, generate new seed & not give that Sig a copy until after the visit... but, if not trust your friends ?...

which leads to my last critique of using big bank's security vaults & new, centralized "key" companies... how can that scale?...

we need p2p solutions!

again, THANKS so much !!! for taking the time & energy to review & comment... and for all your work on these topics ! warm wishes : )

[JayOceans]

considering all the Bitcoiners who have been specifically-targeted,

// here's lopp's repo, regarding https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md

We suggest it primarily as a solution for the risk of Theft, particularly internal or institutional theft.

please, consider adding -- defending against "Physical Theft, Sophisticated" attacks, make that --> a basic part of your plan...

[JayOceans]

any opinions on "Duress" pass-phrases ?...

We also have not yet found sufficiently strong procedures using BIP-0038 encrypted recovery phrases. Other than Bitrot and Custodial Loss,

since, most wallets allow users to create their own pass-phrases, and since many community leaders, like Pamela Morgan & Satoshi Labs, support the use of "duress" pass-phrases, to deceive a 'Physical Theft, Sophisticated' Attacker, i'm hoping you guys could comment...

i see Many serious problems with this strategy...

which I discuss here-- https://medium.com/@summerstarlight321/the-danger-of-pass-phrases-2606b088b372

[maaku]

Be advised that 8 of the 11 bits represented by the final word in a 24-word BIP 39 mnemonic is checksum data and not part of the entropy. With some other choices of entropy bits and number of split shares the distinction can be meaningful.

On Apr 4, 2019, at 4:19 PM, Shannon Appelcline notifications@github.com wrote:

It's also important to note that splitting your keys into three 16-word sets is an alternative to having all 24 of your words in the same place. Yes, 80 bits is less than 256 bits, and as Christopher noted, we suggest immediately changing your master seed if you lose one of your metal devices. But, it's more than 0 bits, which is the actual alternative, and in that case your digital assets would already be gone as soon as you lost that device.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BlockchainCommons/SmartCustodyWhitePapers/issues/2#issuecomment-480096859, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEOIgUmmc-fuc3Qc5BjnEsFyQrMNXHGks5vdoiMgaJpZM4cWVQ6.

[JayOceans]

Be advised that 8 of the 11 bits represented by the final word in a 24-word BIP 39 mnemonic is checksum data and not part of the entropy. With some other choices of entropy bits and number of split shares the distinction can be meaningful.

Awesome!!! i've been looking for that Info, thanks!

[maaku]

Actually one thing that concerns me is if the seed is used directly as a signing key, rather than an HD wallet construction. Finding one share would tell you some of the bits of the actual secret used in signing, and that coupled with examples of signatures (e.g. from transactions on the block chain, or a self-signed key) might be enough to break the remaining key material.

[ChristopherA]

@maaku I don't know of any cases where the seed is used as a signing key — isn't all all cases where an xprv is hash derived from the Recovery Phrase, that the first key used is itself an HD derived from that xprv? Even in Bitcoin Core (which doesn't support Recovery Phrase but does support xprv?

In the case of the scenario in this document, I know that Ledger doesn't used ever use the seed, it always uses the BIP-0044 and segwit HD derivations for keys to sign.

[maaku]

Well BIP 39 just defines the mnemonic encoding of a secret. That secret could alternatively be, e.g., a single bitcoin private key. That's not how it's being used here in this document, but I just wanted to point out the potential misuse. Someone might already have a key-reuse wallet that they want to store the secret for and decide to do this, even though the document itself recommends HD wallets.