From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTxg8-0006BZ-Sb for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:08:24 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.181 as permitted sender) client-ip=209.85.216.181; envelope-from=etotheipi@gmail.com; helo=mail-qc0-f181.google.com; Received: from mail-qc0-f181.google.com ([209.85.216.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTxg8-0006PC-6X for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:08:24 +0000 Received: by mail-qc0-f181.google.com with SMTP id e9so7207242qcy.26 for ; Sat, 29 Mar 2014 11:08:18 -0700 (PDT) X-Received: by 10.140.102.17 with SMTP id v17mr14503247qge.8.1396116498793; Sat, 29 Mar 2014 11:08:18 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id 21sm12125170qgh.23.2014.03.29.11.08.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Mar 2014 11:08:18 -0700 (PDT) Message-ID: <53370C11.7040109@gmail.com> Date: Sat, 29 Mar 2014 14:08:17 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Matt Whitlock References: <15872432.k8h0hUxqlf@crushinator> <53370854.5050303@gmail.com> <2135731.4HGHfZWzo5@crushinator> In-Reply-To: <2135731.4HGHfZWzo5@crushinator> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WTxg8-0006PC-6X Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 18:08:25 -0000 On 03/29/2014 02:00 PM, Matt Whitlock wrote: > On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote: >> On 03/29/2014 01:19 PM, Matt Whitlock wrote: >>> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional. >> I do not believe this is a good tradeoff. It's basically obfuscation of >> something that is already considered secure at the expense of >> usability. It's much more important to me that the user understands >> what is in their hands (or their family members after they get hit by a >> bus), than to obfuscate the parameters of the secret sharing to provide >> a tiny disadvantage to an adversary who gets ahold of one. >> >> The fact that it fails silently is really all downside, not a benefit. >> If I have enough fragments, I can reconstruct the seed and see that it >> produces addresses with money. If not, I know I need more fragments. >> I'm much more concerned about my family having all the info they need to >> recover the money, than an attacker knowing that he needs two more >> fragments instead of which are well-secured anyway. > For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.) Regardless of how SSSS does it, I believe that obfuscating that information is bad news from a usability perspective. Undoubtedly, users will make lots of backups of lots of wallets and think they remember the M-parameter but don't. They will accidentally mix in some 3-of-5 fragments with their 2-of-4 not realizing they are incompatible, or not able to distinguish them. Or they'll distribute too many thinking the threshold is higher and end up insecure, or possibly not have enough fragments to restore their wallet thinking the M-value was lower than it actually was. I just don't see the value in adding such complexity for the benefit of obfuscating information an attacker might be able to figure out anyway (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because he doesn't know where the other frags are and they are actually in safe-deposit boxes)