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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTxo6-00074R-1G for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:16:38 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WTxo4-0006fm-36 for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 18:16:38 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WTxnx-0004yh-6s; Sat, 29 Mar 2014 19:16:29 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_F4DD87E0-15B5-4313-887A-C78574E68B24"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tamas Blummer In-Reply-To: <53370854.5050303@gmail.com> Date: Sat, 29 Mar 2014 19:16:28 +0100 Message-Id: <19FE9882-7FC2-4518-BD50-8818B059271B@bitsofproof.com> References: <4906130.DUyjhm1C93@crushinator> <5336FBE7.7030209@gmail.com> <15872432.k8h0hUxqlf@crushinator> <53370854.5050303@gmail.com> To: Alan Reiner X-Mailer: Apple Mail (2.1510) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396116996; 7978ee6c; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WTxo4-0006fm-36 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:16:38 -0000 --Apple-Mail=_F4DD87E0-15B5-4313-887A-C78574E68B24 Content-Type: multipart/alternative; boundary="Apple-Mail=_E3FC2F3D-C240-43DE-B860-1AF00BC883C3" --Apple-Mail=_E3FC2F3D-C240-43DE-B860-1AF00BC883C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > 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.=20 >=20 > The fact that it fails silently is really all downside, not a benefit.=20= > 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.=20= > 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. >=20 >=20 >=20 > = --------------------------------------------------------------------------= ---- > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --Apple-Mail=_E3FC2F3D-C240-43DE-B860-1AF00BC883C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.

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-developm= ent@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi= nfo/bitcoin-development


= --Apple-Mail=_E3FC2F3D-C240-43DE-B860-1AF00BC883C3-- --Apple-Mail=_F4DD87E0-15B5-4313-887A-C78574E68B24 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTNw38AAoJEPZykcUXcTkcCVkH/jO9W8GMcKuER0UdLA1YnyQ7 lIsIe2l3Mhf9ouUjatu56COJ2eZIm1eh6PBZSHHJvqhGLhgpaNnTy55Su4Bbwukx OBYo2JVCgJd/04oP0eTmPr0Lrxu59rx5Yt9axIu/v5azS6HvNiTKdCWm1C6kjdew tYMGuSoNAByYIOqO+YBhFn3a4AYzF6aiLRB0Rzap1ZOyH1iqjst8j6dgWf8Ly9zG YBBAJcHB+mAeGIBzh2RxiD34wpMJiitJMZEzwavYh8kCFD9XFVdqJ1T4qJa3LdqI ZRuJ9/Xxoa66xAs/wG3IQxFzq15hvOYSk24MTQHuG5JlYgraRjbk8QL7wm5IyS8= =QMZn -----END PGP SIGNATURE----- --Apple-Mail=_F4DD87E0-15B5-4313-887A-C78574E68B24--