summaryrefslogtreecommitdiff
path: root/00/36629407dd887ee8fbc8ef4e4b74222e1d9941
blob: ebb4820cb6ce1a8522d7a90ecaeb235379355da7 (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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 118C6918
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 19:26:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6363485
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 19:26:52 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id l19so734553wmi.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 12:26:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=S8XpsGJ/aKGYQ6guy6+UqG3v6M8PfSL4Jeur1tSSToY=;
	b=HHGfp2AJgR7UOQ0NPabBWE8L1VvlnEu5OwOsb7bF34UcOwWGdQEX5+x6TSJjvmeWVY
	Si1buVzc/tWbq1d+BczOAWMYnkx8vyCxZ835w07q/IJrwl3Ems4LXE6GazlgpXkCxg9T
	R4UVnP0ABmN3PiJNk/lwAwAUDARd3UbE41385EwF6mTxe9alYDQ79MIhot/TV9Jtuk5G
	fuDirG+wdkecL4vOqjAE2pEwytewmipH+jV4O4O6dtYriIzoWuKu8E/f1EP65IiM9pk0
	AQ35mYXy7L6b8HLbZC9gFR4Dr0uFcj3lKsRHt0rhX7LmvnlLa1NETGLyWQa9X6bFb2im
	7gZw==
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=S8XpsGJ/aKGYQ6guy6+UqG3v6M8PfSL4Jeur1tSSToY=;
	b=WzC7gaBT1EQs4HxF/upTw1d02i4YR2xtXkVcVSKZ1jnXmnsEfag9sGzg6BQNCgh78l
	cLFPYRnWnZgGGsU1hlotBokuswROauhKPDgZj3cNYP+/DZzkAbOU3XnYuej0Z43Y6h0y
	mbAIrLQUaJr4H+jAyNUiCT1yLHBEgDHT/3YNQWR/NuUrDkVqKr/v2+lgcA1aPEDw08hs
	WSyWQ6sxcehw0xqr+mvKB3R5ftB00H79SPILWCcKQvZZ3SBA9WDQubkxQfPsDxaAATqL
	ScBm1W1EyzKG5POZWvM1ppkpFR1DA7l91DBC4Rp9ljV5EYdqdkar1VaKv1SYMtkEzLMY
	O1Uw==
X-Gm-Message-State: AHYfb5iSPUB3LgoC2DNgBMd9AAMqftDjX1UCr2mF3cPxH+HxICrrSYqZ
	IrETstahdtoF9ylqAO7bOxLfVypXDA==
X-Received: by 10.80.146.220 with SMTP id l28mr951476eda.160.1503430011389;
	Tue, 22 Aug 2017 12:26:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.129.163 with HTTP; Tue, 22 Aug 2017 12:26:30 -0700 (PDT)
In-Reply-To: <5f67d70d-a432-7826-22df-4207580aa1d2@gmail.com>
References: <CAP6ruDR0GrLRNb4TTub+wqpwVPyzHggbomV48kLZU3tvubH73Q@mail.gmail.com>
	<CABaSBaxjGLmiM0+zTk2PoGTt1zEao-k0ADLkT47vx+mcnPACJw@mail.gmail.com>
	<CAB3F3Dv1kuJdu8veNUHa4b58TvWy=BT6zfxdhqEPBQ8rjDfWtA@mail.gmail.com>
	<5f67d70d-a432-7826-22df-4207580aa1d2@gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 22 Aug 2017 12:26:30 -0700
Message-ID: <CAB3F3Dt6zo_SHAUL72czPZTkh6T9sA3G93wC52Agfd1e3+kKXQ@mail.gmail.com>
To: Jochen Hoenicke <hoenicke@gmail.com>
Content-Type: multipart/alternative; boundary="f403045c1b50c60e4a05575c931b"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin
 Transaction (PSBT) format
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: Tue, 22 Aug 2017 19:26:53 -0000

--f403045c1b50c60e4a05575c931b
Content-Type: text/plain; charset="UTF-8"

If 'x' is public, that makes it identifiable and privacy-losing across
inputs.

To avoid "re-use" I suppose you'd want to sign some message like
`HMAC("ownership proof", H(A || x) )` instead. Otherwise any signature you
make using `A` ends up being used as a proof you don't know the input(this
seems like just details but to be more clear)...

To reiterate:

Sign `HMAC("ownership proof", H(A || x) )` using `A`. Public verifiers see
`HMAC("ownership proof", some_random_hash_connected_to_A )` and the HWW
that owns that input can recreate `some_random_hash_connected_to_A` by `H(A
|| x) )`

On Mon, Aug 21, 2017 at 2:36 PM, Jochen Hoenicke <hoenicke@gmail.com> wrote:

> On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote:
> > To fix this I consulted with andytoshi and got something we think works
> > for both cases:
> >
> > 1) When a signing device receives a partially signed transaction, all
> > inputs must come with a ownership proof:
> > - For the input at address A, a signature over H(A || x) using the key
> > for A. 'x' is some private fixed key that only the signing device
> > knows(most likely some privkey along some unique bip32 path).
> > - For each input ownership proof, the HW wallet validates each signature
> > over the hashed message, then attempts to "decode" the hash by applying
> > its own 'x'. If the hash doesn't match, it cannot be its own input.
> > - Sign for every input that is yours
>
> Interesting, basically a proof of non-ownership :), a proof that the
> hardware wallet doesn't own the address.
>
> But shouldn't x be public, so that the device can verify the signature?
> Can you expand on this, what is exactly signed with which key and how is
> it checked?
>
> One also has to make sure that it's not possible to reuse signatures as
> ownership proof that were made for a different purpose.
>
>   Jochen
>

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

<div dir=3D"ltr">If &#39;x&#39; is public, that makes it identifiable and p=
rivacy-losing across inputs.<div><div><br></div><div>To avoid &quot;re-use&=
quot; I suppose you&#39;d want to sign some message like `HMAC(&quot;owners=
hip proof&quot;, H(A || x) )` instead. Otherwise any signature you make usi=
ng `A` ends up being used as a proof you don&#39;t know the input(this seem=
s like just details but to be more clear)...</div></div><div><br></div><div=
>To reiterate:</div><div><br></div><div>Sign `HMAC(&quot;ownership proof&qu=
ot;, H(A || x) )` using `A`. Public verifiers see `HMAC(&quot;ownership pro=
of&quot;, some_random_hash_connected_to_A )` and the HWW that owns that inp=
ut can recreate `some_random_hash_connected_to_A` by `H(A || x) )`</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 21=
, 2017 at 2:36 PM, Jochen Hoenicke <span dir=3D"ltr">&lt;<a href=3D"mailto:=
hoenicke@gmail.com" target=3D"_blank">hoenicke@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">On <a href=3D"tel:21=
.08.2017%2020" value=3D"+12108201720">21.08.2017 20</a>:12, Greg Sanders vi=
a bitcoin-dev wrote:<br>
&gt; To fix this I consulted with andytoshi and got something we think work=
s<br>
&gt; for both cases:<br>
&gt;<br>
&gt; 1) When a signing device receives a partially signed transaction, all<=
br>
&gt; inputs must come with a ownership proof:<br>
&gt; - For the input at address A, a signature over H(A || x) using the key=
<br>
&gt; for A. &#39;x&#39; is some private fixed key that only the signing dev=
ice<br>
&gt; knows(most likely some privkey along some unique bip32 path).<br>
&gt; - For each input ownership proof, the HW wallet validates each signatu=
re<br>
&gt; over the hashed message, then attempts to &quot;decode&quot; the hash =
by applying<br>
&gt; its own &#39;x&#39;. If the hash doesn&#39;t match, it cannot be its o=
wn input.<br>
&gt; - Sign for every input that is yours<br>
<br>
</span>Interesting, basically a proof of non-ownership :), a proof that the=
<br>
hardware wallet doesn&#39;t own the address.<br>
<br>
But shouldn&#39;t x be public, so that the device can verify the signature?=
<br>
Can you expand on this, what is exactly signed with which key and how is<br=
>
it checked?<br>
<br>
One also has to make sure that it&#39;s not possible to reuse signatures as=
<br>
ownership proof that were made for a different purpose.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=C2=A0 Jochen<br>
</font></span></blockquote></div><br></div>

--f403045c1b50c60e4a05575c931b--