From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C19ABF5A for ; Thu, 18 Jan 2018 13:51:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.sldev.cz (mail.sldev.cz [51.254.7.247]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2BD485C2 for ; Thu, 18 Jan 2018 13:51:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id 4945BEB45; Thu, 18 Jan 2018 14:17:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.sldev.cz Received: from mail.sldev.cz ([127.0.0.1]) by localhost (mail.sl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq8M-eKEkeTD; Thu, 18 Jan 2018 14:17:21 +0000 (UTC) Received: from localhost.localdomain (unknown [10.8.8.156]) by mail.sldev.cz (Postfix) with ESMTPSA id C6848E04E; Thu, 18 Jan 2018 14:17:21 +0000 (UTC) To: Gregory Maxwell , roconnor@blockstream.io, bitcoin-dev@lists.linuxfoundation.org References: <51280a45-f86b-3191-d55e-f34e880c1da8@satoshilabs.com> From: =?UTF-8?Q?Ond=c5=99ej_Vejpustek?= Message-ID: <4003eed1-584f-9773-8cf9-6300ebd1eac6@satoshilabs.com> Date: Thu, 18 Jan 2018 14:50:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 18 Jan 2018 15:50:47 +0000 Subject: Re: [bitcoin-dev] Satoshilabs secret shared private key scheme X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 13:51:48 -0000 Thank you for your comments, Gregory and Russell! Gregory, thank you for you explanation of perfect secrecy, there is no need for that, however. I'm professional mathematician and cryptographer. > I read the above > as "these are similar because they are based on math"... They are based on algebra (group and commutative ring theory), which is a great similarity. RSA and SHA, for example, are based on completely distinct parts of mathematics. > Complicated does not mean secure. And from an information theoretic > perspective the hash does almost nothing (other then some small > destruction of entropy due to its lack of perfect uniformity which is > information theoretically equivalent to using a smaller perfect code). > using error correcting codes and truncated hash functions create identical amounts of information theoretic redundancy I agree, see my last note in the previous mail. Adding redundancy by a hash function is more secure than adding redundancy by a linear relations. Just my opinion. I see the difference between RSA and SSS you mentioned and I understand your arguments about perfect secrecy. Just two comments: (1) Our proposal doesn't use SSS for the whole secret, but it divides the secret into bytes and uses SSS for every byte separately. This scheme is weaker because to reconstruct n-th byte it suffices to have n-th bytes from k shares. (2) SSS is information-theoretic secure if you know k-1 or less shares, where k is the threshold. But the proof doesn't hold if you know for example a small part of every share. > It is of no use to apply the precautionary principle against impossible attacks, especially at the cost of losing the useful properties of a real error correcting codes that would provide actual guarantees against likely errors. The discussion isn't about mathematics or about security proofs but about cryptographic scheme design. In our use case you cannot assume that all premises of security proof theorems (including SSS's perfect secrecy) hold true (see the comment above). In my opinion, to make a cryptographic scheme more robust it's better to stick to general "intuitive" principles. Of course you have to consider the advantages and disadvantages of this approach. That's why we disclosed our draft and welcome all comments. > The discussion of using a proper code was primarily related to the > outer check value which protects the shares themselves and is sitting > unprotected in plaintext OK then. I was defending the hash in the inner check value.