Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTyC4-000546-Py for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:41:24 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.54 as permitted sender) client-ip=209.85.192.54; envelope-from=etotheipi@gmail.com; helo=mail-qg0-f54.google.com; Received: from mail-qg0-f54.google.com ([209.85.192.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTyC3-0007Lw-NW for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:41:24 +0000 Received: by mail-qg0-f54.google.com with SMTP id a108so2281420qge.13 for ; Sat, 29 Mar 2014 11:41:18 -0700 (PDT) X-Received: by 10.224.161.15 with SMTP id p15mr16459602qax.46.1396118478228; Sat, 29 Mar 2014 11:41: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 b36sm12231196qga.15.2014.03.29.11.41.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Mar 2014 11:41:17 -0700 (PDT) Message-ID: <533713CD.3070403@gmail.com> Date: Sat, 29 Mar 2014 14:41: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: Tamas Blummer References: <4906130.DUyjhm1C93@crushinator> <5336FBE7.7030209@gmail.com> <15872432.k8h0hUxqlf@crushinator> <53370854.5050303@gmail.com> <19FE9882-7FC2-4518-BD50-8818B059271B@bitsofproof.com> In-Reply-To: <19FE9882-7FC2-4518-BD50-8818B059271B@bitsofproof.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020904030404000102000300" X-Spam-Score: -0.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 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1WTyC3-0007Lw-NW 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:41:25 -0000 This is a multi-part message in MIME format. --------------020904030404000102000300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Armory does exactly this: it defines the "Fragment ID" as the first few bytes of the hash of the root pubKey + M-parameter, converted to base58. Then it explains to the user "All fragments with the same fragment ID are compatible" (which only works if you use deterministic coefficients). Each fragment is then labeled with "[FragID]-#1", "[FragID]-#2", etc. It became quite useful for organizing the fragments and documenting how I was distributing them, especially if I had printed or saved the same fragment twice by accident. On 03/29/2014 02:16 PM, Tamas Blummer wrote: > I also think that we can add usability features if the underlying > secret remains well protected. > I do not think there is any reason to assume that the knowledge of the > degree of the polynomial, would aid an attacker. > > Similarly a fingerprint of the secret if it is unrelated to the hash > used in the polinomyal should leak no useful information, > > The length of such fingerpring (say 4 bytes) and the degree (1 byte) > does not seem a big overhead for me. > > Remember that the biggest obstacle of Bitcoin is usability not security. > > Regards, > > Tamas Blummer > http://bitsofproof.com > > On 29.03.2014, at 18:52, 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. >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > --------------020904030404000102000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Armory does exactly this: it defines the "Fragment ID" as the first few bytes of the hash of the root pubKey + M-parameter, converted to base58. Then it explains to the user "All fragments with the same fragment ID are compatible" (which only works if you use deterministic coefficients). Each fragment is then labeled with "[FragID]-#1", "[FragID]-#2", etc. It became quite useful for organizing the fragments and documenting how I was distributing them, especially if I had printed or saved the same fragment twice by accident.

On 03/29/2014 02:16 PM, Tamas Blummer wrote:

I also think that we can add usability features if the underlying secret remains well protected.
I do not think there is any reason to assume that the knowledge of the degree of the polynomial, would aid an attacker.

Similarly a fingerprint of the secret if it is unrelated to the hash used in the polinomyal should leak no useful information,

The length of such fingerpring (say 4 bytes) and the degree (1 byte) does not seem a big overhead for me.

Remember that the biggest obstacle of Bitcoin is usability not security.

Regards,

Tamas Blummer
http://bitsofproof.com

On 29.03.2014, at 18:52, Alan Reiner <etotheipi@gmail.com> 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.

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------020904030404000102000300--