summaryrefslogtreecommitdiff
path: root/f2/b52c85e98f688e043d0690c3f1a1c79752e47b
blob: fae007513c5c7fe3f1bada59c05d3795d2d8512b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C4823F50
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 19:21:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f50.google.com (mail-it0-f50.google.com
	[209.85.214.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3031E271
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 19:21:35 +0000 (UTC)
Received: by mail-it0-f50.google.com with SMTP id p124so10973182ite.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 11:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=3m6fTtdZGDEEQTt+44s1x/Ch8FbnFqPK1YXi0uTjw0w=;
	b=EruVDp/7bSi+4Ge4w5m5RGVYlyRn2QJSbnF22c/Sj+uC1NLxZWJVOHCwlMaUnUO7sF
	H9615SWGMhMvlhrGHTpYm9zJTzBjCtkBau/5QC+5QjAPe3su/Y54FIa2kP8GWaBd2pRi
	TTF5VSsNELmXTclHk7i7yzi9oNzQaxqhoPJZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=3m6fTtdZGDEEQTt+44s1x/Ch8FbnFqPK1YXi0uTjw0w=;
	b=dTG6cGXpDUMHqIy2SVwZh6mXVuBphKWFQC48xNLLYWV8AdALsXBMuuiZE94T3oMUc3
	0uZQRbTARoSRc3SMJuYVyN72Z2vZwi3OmWSxd6IStpoNMTXvE9n8avrs6Y1yyu3Mhpbr
	hO+Y79Eh/3wVBPYpA7EPHBudVRu2daF5guuXR7ChoDZh1AHa42fgAEpvAzrbqufWo2cn
	b67w14mR85tvWPMOOfcG2uzknXoQ9bafzu9WoWiDHVl8sZ8wX08f7SiLYdfXoK1eWtwC
	RlROLMhtbj7N3kpFQ03r6ICcwL/EDHJZRgqSPmhGKWD/mkwrOL2vIS250SybQ70AcKOc
	I3fQ==
X-Gm-Message-State: AKwxyteVSQ1nP4hTfMxsrfo0Z5ffmQODYFphSQTjkhSpoVdDHcKY8w13
	0Z2kkA3GvMg2a8l2Ma7+1i65JZL5oFJL4MrtLpfTXjelW08=
X-Google-Smtp-Source: AH8x224XaOE8xs8N7/GPCoXNVftaawnsKIK2q3MV7QDT6PcANoB/aHfP/zY3sDWqHtltN2zcf/o+lLb672PSNE1ZzGQ=
X-Received: by 10.36.215.69 with SMTP id y66mr9574735itg.10.1516648894395;
	Mon, 22 Jan 2018 11:21:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.120.10 with HTTP; Mon, 22 Jan 2018 11:21:14 -0800 (PST)
In-Reply-To: <CAAS2fgQtf_LDDcWDmvM+kjPCSqaQVwVd2rKWVtho4-XSAHpJZQ@mail.gmail.com>
References: <51280a45-f86b-3191-d55e-f34e880c1da8@satoshilabs.com>
	<CAAS2fgRQk4EUp6FO2f+RkJpDTyZX0N4=uGp7ZF=0aUchZX8hSA@mail.gmail.com>
	<4003eed1-584f-9773-8cf9-6300ebd1eac6@satoshilabs.com>
	<CAAS2fgSw0mAQPJ-ai-3kFr7pWXd7pjbrEoXN4r6Ak3o4c8_vjw@mail.gmail.com>
	<d6eb0fc3-d729-30cb-986b-b1d7b8aacbd6@satoshilabs.com>
	<CAAS2fgQtf_LDDcWDmvM+kjPCSqaQVwVd2rKWVtho4-XSAHpJZQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 22 Jan 2018 14:21:14 -0500
Message-ID: <CAMZUoK=ffKHM9WN=zrSME5y904u6ZYsfnCpeT_BYT=5Z+NxYsw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0afc44999db005636256e7"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Mon, 22 Jan 2018 20:11:35 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2018 19:21:35 -0000

--94eb2c0afc44999db005636256e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Jan 18, 2018 at 4:59 PM, Ond=C5=99ej Vejpustek
> <ondrej.vejpustek@satoshilabs.com> wrote:
> >> 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.
>
> My post provided a concrete example. I'd be happy to answer any
> questions about it, but otherwise I'm not sure how to make it more
> clear.
>
> > 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.
>
>
> Quite the opposite-- a large block cipher is a standard
> construction... and the off-label application of a KDF that you've
> used here doesn't provide any protection against the example I gave.
>

At this point, is it better just to use GF(2^256+n)?  Is GF(2^256+n) going
to be that much slower than GF(2^8) that we care to make things this
complicated?  (I honestly don't know the answer.)

--94eb2c0afc44999db005636256e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On Thu=
, Jan 18, 2018 at 4:59 PM, Ond=C5=99ej Vejpustek<br>
&lt;<a href=3D"mailto:ondrej.vejpustek@satoshilabs.com">ondrej.vejpustek@sa=
toshilabs.<wbr>com</a>&gt; wrote:<br>
&gt;&gt; If being secure against partial share leakage is really part of yo=
ur<br>
&gt;&gt; threat model the current proposal is gratuitously insecure against=
 it.<br>
&gt;<br>
&gt; I don&#39;t think that is true. Shared secret is an input of KDF which=
<br>
&gt; should prevent this kind of attack.<br>
<br>
</span>My post provided a concrete example. I&#39;d be happy to answer any<=
br>
questions about it, but otherwise I&#39;m not sure how to make it more<br>
clear.<br>
<span class=3D"gmail-"><br>
&gt; Actually, we&#39;ve been considering something like that. We concluded=
 that it is to much &quot;rolling your own crypto&quot;. Instead of diffusi=
on layer we decided to apply KDF on the shared secret.<br>
<br>
<br>
</span>Quite the opposite-- a large block cipher is a standard<br>
construction... and the off-label application of a KDF that you&#39;ve<br>
used here doesn&#39;t provide any protection against the example I gave.<di=
v></div></blockquote><div><br></div>At this point, is it better just to use=
 GF(2^256+n)?=C2=A0 Is GF(2^256+n) going to be that much slower than GF(2^8=
) that we care to make things this complicated?=C2=A0 (I honestly don&#39;t=
 know the answer.)<br></div></div></div>

--94eb2c0afc44999db005636256e7--