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
|
Return-Path: <roconnor@blockstream.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7415FC07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Mar 2020 17:00:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 5AF6F88521
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Mar 2020 17:00:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bNi3t-ybixqh
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Mar 2020 17:00:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com
[209.85.166.181])
by hemlock.osuosl.org (Postfix) with ESMTPS id E21BA884FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Mar 2020 16:59:59 +0000 (UTC)
Received: by mail-il1-f181.google.com with SMTP id o16so6313521ilm.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Mar 2020 09:59:59 -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;
bh=wPr/QLM8M4kiMA0FV+Ox3Yl21ESqU0q2FLOioaYmAQ4=;
b=zAUwnO26Ye23u/FJyfG+QzWPTH/gd6O3Bu3o4YCuTeuq2Pp8sMfFo7lDKfroz8PAym
iaOBbPe3YSB3qtV171ifAw7hnEX+7fbTVLCFeewiP60K6DsMbf+g5DF4dZJ/zJlqEWbQ
cOh7oE8FMvVef4oaCjJzbHUUftR0ufLmSaUlpTFdU2awEZWr3CGmwKQqTYjc9KMQ1oVU
t57ozj2JZuLtslaeds2InGI1CAnVfchHD9sv33wL4OFNjp3/LxRet9o960gXc+CGFUgw
69oZzdYbhPHwBvw52PPVpbVtAQ9KzXlxq3J9bureHxqJ6rRugHh0Js7LraCeXYfXkBVQ
Qtkw==
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;
bh=wPr/QLM8M4kiMA0FV+Ox3Yl21ESqU0q2FLOioaYmAQ4=;
b=kCD9pdb2JJ3RPcZW3tiNUHOyM6qswUMJ25scNUzhnKxOJAXZIJIY4GuIzxGwjc7yEw
BUlEnDx4s0vXtBO73xkcN+3qNXtyjA7pdYW70mRkzJHpBM7hjqCRNgx0U0lWb3jIQ0Oy
aMaIyWlzlIUIj20PhjAkfq3Sdm+1gzbQevjU2osKWXirpbWBlgHzpH7UoYac02vXCgtr
BL3JyF6+/tlClO19bbWuyaYvOBRgZ4Manol8r9weRONTsfr9jz2eTqGYnlgG9WxbaQ0P
T81/1DQr8tkhMLmRussPeBq8t0B/ea4ozpAZ3qzUPT9sBrU+KbtTfnUHRWq5OjoUNVbr
eTTQ==
X-Gm-Message-State: ANhLgQ04MNdl4JNd2LPbVEtI54PxCCvPnEgbA/hBu3wnztdQ0hHtbEHL
7XCB36GLpc9oF8A9NzsSaQtdbMjrOXJW9dEYujhI6NeZ
X-Google-Smtp-Source: ADFU+vuymKGvV0yTRp1QUS6bPG4uSljEwt61W8545Rj14bUUsC69kVhJs9ef5dxh4T+hKfbfCfWowuqS3zXYjaEZwmQ=
X-Received: by 2002:a92:5a88:: with SMTP id b8mr2771725ilg.151.1584809999037;
Sat, 21 Mar 2020 09:59:59 -0700 (PDT)
MIME-Version: 1.0
References: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
<de7bd393327015a5b97ffff0d15a7c90d2d2196a.camel@timruffing.de>
In-Reply-To: <de7bd393327015a5b97ffff0d15a7c90d2d2196a.camel@timruffing.de>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 21 Mar 2020 12:59:47 -0400
Message-ID: <CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com>
To: Tim Ruffing <crypto@timruffing.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000078e9505a1605506"
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: Sat, 21 Mar 2020 17:00:03 -0000
--000000000000078e9505a1605506
Content-Type: text/plain; charset="UTF-8"
On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> Let's take a step back first. If we believe that malicious hardware
> wallets are big enough of a concern, then signing is only part of the
> problem. The other issue is key generation. The PRG from which the seed
> is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO
> chosen by the hardware manufacturer. I haven't seen an argument why
> attacks during the signing model should more realistic than attacks
> during key generation, so I'd be very hesitant to deploy anti-covert
> channel singing protocols without deploying protocols for key
> generation that are secure in the same attacker model.
>
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.
--000000000000078e9505a1605506
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing =
via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Hi Pieter, <br>
<br>
Let's take a step back first. If we believe that malicious hardware<br>
wallets are big enough of a concern, then signing is only part of the<br>
problem. The other issue is key generation. The PRG from which the seed<br>
is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO<br>
chosen by the hardware manufacturer. I haven't seen an argument why<br>
attacks during the signing model should more realistic than attacks<br>
during key generation, so I'd be very hesitant to deploy anti-covert<br=
>
channel singing protocols without deploying protocols for key<br>
generation that are secure in the same attacker model.<br></blockquote><div=
><br></div><div>Public keys are deterministic and can be spot checked.=C2=
=A0 In fact, AFAIU if hardened HD key derivations are not used, then spot c=
hecking is very easy.</div><div><br></div><div>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.=C2=
=A0 This is why anti-covert signing protocols are so important if we are go=
ing to use synthetic nonces.<br></div></div></div>
--000000000000078e9505a1605506--
|
