Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1WTxQh-0003Ub-6K
	for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 17:52:27 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.170 as permitted sender)
	client-ip=209.85.216.170; envelope-from=etotheipi@gmail.com;
	helo=mail-qc0-f170.google.com; 
Received: from mail-qc0-f170.google.com ([209.85.216.170])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WTxQg-0001BZ-IG
	for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 17:52:27 +0000
Received: by mail-qc0-f170.google.com with SMTP id e9so7471981qcy.29
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 29 Mar 2014 10:52:21 -0700 (PDT)
X-Received: by 10.140.31.66 with SMTP id e60mr2581224qge.76.1396115541124;
	Sat, 29 Mar 2014 10:52:21 -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 y9sm17449787qai.13.2014.03.29.10.52.20
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 29 Mar 2014 10:52:20 -0700 (PDT)
Message-ID: <53370854.5050303@gmail.com>
Date: Sat, 29 Mar 2014 13:52:20 -0400
From: Alan Reiner <etotheipi@gmail.com>
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 <bip@mattwhitlock.name>
References: <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
	<4906130.DUyjhm1C93@crushinator> <5336FBE7.7030209@gmail.com>
	<15872432.k8h0hUxqlf@crushinator>
In-Reply-To: <15872432.k8h0hUxqlf@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: 1WTxQg-0001BZ-IG
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 29 Mar 2014 17:52:27 -0000

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.