From: Andrew Kozlik <andrew.kozlik@satoshilabs•com>
To: Christopher Allen <ChristopherA@lifewithalacrity•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes
Date: Wed, 26 Sep 2018 14:12:40 +0200 [thread overview]
Message-ID: <5c36fdb3-304f-ce43-d41a-0c1d66c7cc41@satoshilabs.com> (raw)
In-Reply-To: <CACrqygCoqFMFLTpn5PSMR2_wSHnWsXSyZZ_jhk-FbvZHwwz4nA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5279 bytes --]
Thanks for your input Christopher. Since we already have the discussion
about your comments running under the issues in the SLIPs repo on Github
(https://github.com/satoshilabs/slips/issues), let's continue it there.
Andrew Kozlik
On 21.9.2018 21:29, Christopher Allen wrote:
> On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> We are currently writing a new specification for splitting BIP-32
> master
> seeds into multiple mnemonics using Shamir's secret sharing scheme. We
> would be interested in getting your feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions.
> Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed
> once the
> high level design has been settled.
>
>
> I and a number of companies & communities I am involved with are very
> interested in this.
>
> A challenge is that Shamir Secret Sharing has subtleties. To quote
> Greg Maxwell:
>
> > I think Shamir Secret Sharing (and a number of other things, RNGs
> for example), suffer from a property where they are just complex
> enough that people are excited to implement them often for little good
> reason, and then they are complex enough (or have few enough reasons
> to invest significant time) they implement them poorly”.
>
> Some questions for you:
>
> * What other teams or communities besides Trezor are committed to
> standardizing a Shamir Secret Sharing Scheme? I can say that the
> #RebootingWebOfTrust community (meeting again for the 7th time next
> week in Toronto https://rwot7.eventbrite.com) are very interested.
>
> * Where do you want to hold discussions on this? Do people object to
> having this discussion on this mailing list? Or should it be issues in
> SLIPS repo or on some other mailing list?
>
> * Presuming a successful split of secrets, I don’t know all the
> adversarial problems that are associated with recovery of a SSS. As
> this would be an interactive event, I presume an attacker can DOS a
> request to reassemble keys (so maybe some the of integrity of each
> share vs all is required). And of course there are the biggest
> problems: impersonation of a reassembly request and a MitM of a
> reassembly request. Are there other attacks? Are you trying to
> mitigate any of these?
>
> Two comments:
>
> * The Lightning Network community has added to their BIP32 mnemonics
> the ability to have a birthday in the seed, to make it easier to scan
> the blockchain for keys, as well as a byte with some way to know how
> to derive keys paths for it. I don’t seee a BOLT for this (it was
> mentioned
> in https://bitcoin.stackexchange.com/questions/74805/what-is-birthday-in-the-context-of-bip39-lightning-seed-generation)
> I would suggest that you also get some of their latest thoughts and
> incorporate them.
>
> * I worked with Chris Vickery while at Blockstrham on various possible
> ways to improve mnemonic word lists. I’m not suggesting that you
> necessarily go as far as we did to try to create a mnemonic that is
> iambic pentameter poetry (inspired by
> https://www.isi.edu/natural-language/mt/memorize-random-60.pdf),
> however, we did find sources for words that are concrete (for example
> table is more concrete than truth
> http://crr.ugent.be/papers/Brysbaert_Warriner_Kuperman_BRM_Concreteness_ratings.pdf
> ) or have strong emotional valence attachment (truth is more emotional
> than table), both of which make can words more memorable. I also found
> lists of words that are hard to pronounce unless you are English
> native, and eliminated them from my own list.
>
> Among the results of this was a new BIP-39 2048 word compatible word
> list filtered for memorability (concreteness & emotional valence) and
> suitability for iambic pentameter, which is located:
>
>
> https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/iambic-wordlist.json
>
> …which was created from the repo at
>
> https://github.com/ChristopherA/password_poem
>
> You can a number of other word lists that I’ve collected here
> https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/
>
> If you want to replicate what we did with your own criteria, you may
> want to incorporate information from the CMU
> dictitionary http://www.speech.cs.cmu.edu/cgi-bin/cmudict, the top
> 5000
> words https://github.com/ChristopherA/password_poem/blob/master/top5000.json,
> concrete word lists
> http://crr.ugent.be/papers/Concreteness_ratings_Brysbaert_et_al_BRM.txt
> and emotional words (valence) http://crr.ugent.be/archives/1003
>
> — Christopher Allen
>
>
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 21466 bytes --]
next prev parent reply other threads:[~2018-09-26 12:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 16:19 Andrew Kozlik
2018-09-21 19:29 ` Christopher Allen
2018-09-22 4:54 ` vizeet srivastava
2018-09-26 12:12 ` Andrew Kozlik [this message]
2018-09-24 19:49 ` Ignacio Berrozpe
2018-09-26 13:44 ` Andrew Kozlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c36fdb3-304f-ce43-d41a-0c1d66c7cc41@satoshilabs.com \
--to=andrew.kozlik@satoshilabs$(echo .)com \
--cc=ChristopherA@lifewithalacrity$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox