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 F3D9E1033 for ; Thu, 18 Jan 2018 17:00:15 +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 807E851E for ; Thu, 18 Jan 2018 17:00:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id 154F6EB45; Thu, 18 Jan 2018 17:25:51 +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 ij9mHvRpm6Mt; Thu, 18 Jan 2018 17:25:50 +0000 (UTC) Received: from localhost.localdomain (unknown [10.8.8.156]) by mail.sldev.cz (Postfix) with ESMTPSA id AF4B8E04E; Thu, 18 Jan 2018 17:25:50 +0000 (UTC) To: Gregory Maxwell References: <51280a45-f86b-3191-d55e-f34e880c1da8@satoshilabs.com> <4003eed1-584f-9773-8cf9-6300ebd1eac6@satoshilabs.com> From: =?UTF-8?Q?Ond=c5=99ej_Vejpustek?= Message-ID: Date: Thu, 18 Jan 2018 17:59:09 +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: 8bit 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 17:09:57 +0000 Cc: Bitcoin Dev 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 17:00:16 -0000 > If being secure against partial share leakage is really part of your > threat model the current proposal is gratuitously insecure against it. I don't think that is true. Shared secret is an input of KDF which should prevent this kind of attack. > If partial share disclosure were an actual concern, I would recommend > that after sharing and before encoding for transmission (e.g. before > applying check values and word encoding to the share) the individual > shares be passed through a large block unkeyed cryptographic > permutation. Under reasonable-ish assumptions about the difficulty of > inverting the permutation with partial knowledge, this transformation > would prevent attacks from leaks of partial share information. Actually, we've been considering something like that. We concluded that it is to much "rolling your own crypto". Instead of diffusion layer we decided to apply KDF on the shared secret.