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
Precedence: list

--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 &lt;<a href=3D"mailt=
o:crypto@timruffing.de">crypto@timruffing.de</a>&gt; 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&#39;Connor wrote:<br>
&gt; Public keys are deterministic and can be spot checked.=C2=A0 In fact,<=
br>
&gt; AFAIU if hardened HD key derivations are not used, then spot checking<=
br>
&gt; is very easy.<br>
&gt; <br>
&gt; While spot checking isn&#39;t ideal, my original concern with the<br>
&gt; synthetic none standard proposal was that it is inherently non-<br>
&gt; deterministic and cannot ever be spot checked.=C2=A0 This is why anti-=
<br>
&gt; covert signing protocols are so important if we are going to use<br>
&gt; 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&#39;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--