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

--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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;t seen an argument why<br>
attacks during the signing model should more realistic than attacks<br>
during key generation, so I&#39;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&#39;=
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--