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
|
Return-Path: <roconnor@blockstream.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89248C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 15:30:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 7492386BC4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 15:30:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qdxg9Ii2N5Y1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 15:30:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com
[209.85.166.170])
by whitealder.osuosl.org (Postfix) with ESMTPS id 42DF786B50
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 15:30:46 +0000 (UTC)
Received: by mail-il1-f170.google.com with SMTP id r5so6005279ilq.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 08:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=YXCwgZLKTVpyh+lSIwEFp3d+m5mBWSekTJeynsdZmUU=;
b=Omote9xsS73DtmRU4+gnNEULT5opH0ItT2QpE+35ytx2ZBszQxtSpXwYNEr4728i5V
U3I4BpYuvjtC9H8Dobt7c/srF6lGMTTWWONaI/A3WEP4yZ3Y4swOJb4mIkv07yR2do3x
bPPChF9kANJcSaf+iVib/sZ5czZ7ldLSGO2zpaHR+qtxlgZXK7ex7otcptOhSRTcWJ8b
EwEofcnA9ioZTaiT0fH3hmvHBVU5PBPYm8xrSqH4YSWpUMkyEy/1QGnQtSyQkI1I5INJ
YXFHVJL/mRSgJtFC0Om8WIxBVT/yfhGGjJqxtSesMH/FB2P30iokVfWt6YncmzuBaRgC
yRSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=YXCwgZLKTVpyh+lSIwEFp3d+m5mBWSekTJeynsdZmUU=;
b=gbaMAjJ4Wll4QgKDGH4dl0Kzz2IXe64PaJw7AoCdKNoXnBdg4gkgGrHF+XXqcedRmV
R+NGvKsEReWZfUbU+pjrWgeftCV5zNmLIzSp7IXiZI4+jwh5pvbcRyG+Pd2ObXz4n1Us
JNEPj8ydqgOzm9msYzsM5KUwMKx1QnI8LXqu+J7YRLKlKKJAuy32Q94wfh0HNeKcH2DK
ZdHIDYmhvfp7ApdyGNGjd5+D3xwDDbYwLzgyidiYTUJsf0bFSYbVYB83VuXWxZRGmlbu
/ALmmFuT79p2SHxO5aIgDzcT+zBALS7ZohuRcObDxK/WPKHwoHfcQUIiv4TqqOnE3nt2
OBQg==
X-Gm-Message-State: ANhLgQ1nxW9PJLfvYOts4KmfRzVLZ5Q42XyWXWRSloUfX8nxhXklHCON
CGHrVxYwzlGqbCscGRhAlO1pL/zjl/GBVrn6Bw2huA==
X-Google-Smtp-Source: ADFU+vu02IZOxbuNo3ebgqtrOjKkK890MFLXI5t6+AMrTW2VtxxCsYNKjOJWZwWzD1OeomgnKn7zRZ+AtOlejT2iHwk=
X-Received: by 2002:a92:5a88:: with SMTP id b8mr6260514ilg.151.1584891045513;
Sun, 22 Mar 2020 08:30:45 -0700 (PDT)
MIME-Version: 1.0
References: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
<de7bd393327015a5b97ffff0d15a7c90d2d2196a.camel@timruffing.de>
<CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com>
<c14db3d600c0c60bbf06ea832fc438a5c9fd97da.camel@timruffing.de>
In-Reply-To: <c14db3d600c0c60bbf06ea832fc438a5c9fd97da.camel@timruffing.de>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sun, 22 Mar 2020 11:30:34 -0400
Message-ID: <CAMZUoKkNvdegQFzosD-_DHZuu+qiCS6dKXvW7vDTpuB+T_j7dg@mail.gmail.com>
To: Tim Ruffing <crypto@timruffing.de>
Content-Type: multipart/alternative; boundary="000000000000c6a3b205a1733304"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sun, 22 Mar 2020 15:30:47 -0000
--000000000000c6a3b205a1733304
Content-Type: text/plain; charset="UTF-8"
On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing <crypto@timruffing.de> wrote:
> On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> > Public keys are deterministic and can be spot checked. In fact,
> > AFAIU if hardened HD key derivations are not used, then spot checking
> > is very easy.
> >
> > While spot checking isn't ideal, my original concern with the
> > synthetic none standard proposal was that it is inherently non-
> > deterministic and cannot ever be spot checked. This is why anti-
> > covert signing protocols are so important if we are going to use
> > synthetic nonces.
>
> If spot checking means checking a few instances, then I think this is a
> pretty weak defense. What if the device starts to behave differently
> after a year?
>
I agree, which is why there perhaps is merit in using a non-hardered
derivation path so that the software side of a hardware wallet can check
the pubkey. Though I understand there are some disadvantages to the
non-hardened paths.
However, spot checking can even be done retroactively (and thoroughly).
Again, I agree that this is less than ideal, but does let you take some
action once you notice a deviation.
Your claim is that if we don't fix the pubkey issue there is no point in
fixing the signature issue. I disagree. While I think both issues need to
be fully addressed, the issues around the original proposed
non-deterministic signature scheme are far more severe. The proposal would
move us from a deterministic scheme, where spot checks are possible, with
all the caveats that entails, to a non-deterministic scheme where spot
checks are impossible. My hope is that we can standardise a scheme that
has the advantages of non-determinism without the threat of covert channels.
--000000000000c6a3b205a1733304
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing <<a href=3D"mailt=
o:crypto@timruffing.de">crypto@timruffing.de</a>> wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On Sat, 2020-03-21 at 12:59 -04=
00, Russell O'Connor wrote:<br>
> Public keys are deterministic and can be spot checked.=C2=A0 In fact,<=
br>
> AFAIU if hardened HD key derivations are not used, then spot checking<=
br>
> is very easy.<br>
> <br>
> While spot checking isn't ideal, my original concern with the<br>
> synthetic none standard proposal was that it is inherently non-<br>
> deterministic and cannot ever be spot checked.=C2=A0 This is why anti-=
<br>
> covert signing protocols are so important if we are going to use<br>
> synthetic nonces.<br>
<br>
If spot checking means checking a few instances, then I think this is a<br>
pretty weak defense. What if the device starts to behave differently<br>
after a year?<br></blockquote><div><br></div><div><div>I agree, which is wh=
y there perhaps is merit in using a=20
non-hardered derivation path so that the software side of a hardware=20
wallet can check the pubkey. Though I understand there are some=20
disadvantages to the non-hardened paths.<br></div><div><div><div><br></div>=
<div>However,
spot checking can even be done retroactively (and thoroughly). Again, I
agree that this is less than ideal, but does let you take some action=20
once you notice a deviation.<br></div></div></div><div><br></div><div>Your
claim is that if we don't fix the pubkey issue there is no point in=20
fixing the signature issue.=C2=A0 I disagree.=C2=A0 While I think both issu=
es need
to be fully addressed, the issues around the original proposed=20
non-deterministic signature scheme are far more severe. The proposal=20
would move us from a deterministic scheme, where spot checks are=20
possible, with all the caveats that entails, to a non-deterministic=20
scheme where spot checks are impossible.=C2=A0 My hope is that we can=20
standardise a scheme that has the advantages of non-determinism without=20
the threat of covert channels.</div></div></div></div>
--000000000000c6a3b205a1733304--
|
