path: root/49/63d8e2a623c3785995b1734264bdac006f35a4

Return-Path: <lloyd.fourn@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 75E83C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Feb 2020 04:55:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 6C77F20467
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Feb 2020 04:55:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id z08EvQ0+cOYI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Feb 2020 04:55:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f177.google.com (mail-il1-f177.google.com
 [209.85.166.177])
 by silver.osuosl.org (Postfix) with ESMTPS id 1C05020013
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Feb 2020 04:55:48 +0000 (UTC)
Received: by mail-il1-f177.google.com with SMTP id p8so1231816iln.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 20:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Kad9gPxjAE2hY1qIUasyX++lvTOOosfAsTAPs03DVG4=;
 b=IALqAE5h4kvEI+ShmP+sgVETfrRdVjOuSslGPSm60H8njLjV2oUxvdLgJjLlXRPbT6
 FWQPJMtI6yZKyj2Vwi2iYgS3l7Ytw2TiqMs75c5YSibygh9mC1/jKSzl6UJyYSKwhN2M
 lqxsZwL8B9CtLnUMaEX5fi3azhq++nmeL2nPjCnONUO0pAsdbDs2Mmw4rWRs/d9PLs28
 gyLWVy8/Jq7R1DAo9//bpB8nCJEQ/qqtbzrSkMHGrzKyh1+BZ1OuluKg38VxbnYGR4bH
 AKWtoWcUNbHg7OYHUfZ1T2h+2rgf0822uMEcToI+P+G/OIKYbFAAqFgDL4/QwD4S9pCh
 ipKA==
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=Kad9gPxjAE2hY1qIUasyX++lvTOOosfAsTAPs03DVG4=;
 b=s7WoKgNQu1gmb5DuglSERqsd0gvxMeNVXYsyBDZaNQzvlmdI7Hy8YCiyHtDfNvLqDz
 /0EvpRs3YlU0M7TVReRwZ10hINr2rrde8wZKBuJIQ6sC9URT/UgF4TF4eKTyEU8WleKN
 mEZ0HGSAXnJ9O8GnorbEiui624AWepOKsFQ1QG5oTLUVSQdH+71coCDoHh6pghaMuvot
 RN4RwjMKrzZqBDQEB3V7yzSsDSm5RzsoqAzy0w1U9+8WuKQtdvw1z3uavJB0+S0eMHL+
 hYyAHBZTs1yd+lkkxpsfHt2Ca7HsH0zk0eVwxNGy6aZvR+Db0xIZHRAzCeRaZFFLAc/0
 zbVw==
X-Gm-Message-State: APjAAAVXdG4M0c3/2UvnCSHWTjvQChSuoFW4MHkvTj40nN7yts39JVbd
 m+VXFUtlY3AtaBmh54FbAvgDUSmDdUaojNTqk0s=
X-Google-Smtp-Source: APXvYqwZfWcsPIKDEN0POW9JWPyeCGMYO8XboBX+gBJu9WbZti4OJnwyVkOmRIsRMeTh8xAerl7cPccemJrFp7EjasI=
X-Received: by 2002:a92:8f4b:: with SMTP id j72mr2814907ild.17.1582779347242; 
 Wed, 26 Feb 2020 20:55:47 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBgxvRM5ncQAnbNLN=4bdkQrM+-DxibMoTG+6gqk7EY9hQ@mail.gmail.com>
 <CAH5Bsr0ws2GT12+1rXTAXUkrpJXaeDqDgkfW_sdz7CqvwRCEkg@mail.gmail.com>
 <ca64cabd-93ef-edf1-1e1f-7d7a48a51587@gmail.com>
In-Reply-To: <ca64cabd-93ef-edf1-1e1f-7d7a48a51587@gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Thu, 27 Feb 2020 15:55:21 +1100
Message-ID: <CAH5Bsr1n8bWrCvAuJvg9Qj-TCdOvqPDJoKNybr0N4YHYjpC+hQ@mail.gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c014fe059f87881b"
X-Mailman-Approved-At: Thu, 27 Feb 2020 05:59:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] BIP 340 updates: even pubkeys,
	more secure nonce generation
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: Thu, 27 Feb 2020 04:55:50 -0000

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

> Correct, except that the speedup from is_even(y) over
is_quadratic_residue(y) affects signing and not keypair generation.

Isn't this the same thing since in the spec it generates the public key in
the signing algorithm? If you pre-generate public key and pass it in there
would be no speedup to signing that I can see.

> It's not clear why removing these features from the spec would be an
improvement.

It could just be me but "here's the most minimal signing algorithm, you can
add things in these ways to make it more robust  in some settings" is more
intuitive than "here's the most robust signing algorithm, you can remove
these things in these ways if they don't apply to your setting". I see your
point that if it is likely to be misused then maybe the latter is
preferable.

LL

On Thu, Feb 27, 2020 at 2:33 AM Jonas Nick <jonasdnick@gmail.com> wrote:

> > Let me put change (1) into my own words.
>
> Correct, except that the speedup from is_even(y) over
> is_quadratic_residue(y)
> affects signing and not keypair generation.
>
> > With change (2), I feel like including this auxiliary random data is
> overkill
> > for the spec. [...] I feel similarly about hashing the public key to get
> the
> > nonce.
>
> It's not clear why removing these features from the spec would be an
> improvement.
> The BIP follows a more reasonable approach: it specifies a reasonably
> secure
> signing algorithm and provides the rationale behind the design choices.
> This
> allows anyone to optimize for their use case if they choose to do so.
> Importantly, "reasonably secure" includes misuse resistance which would be
> violated if the pubkey was not input to the nonce generation function.
>
> > Perhaps they even deserve their own BIP?
>
> Yes, a standard for nonce exfiltration protection and MuSig would be
> important
> for compatibility across wallets.
>
>
> On 2/26/20 4:20 AM, Lloyd Fournier via bitcoin-dev wrote:
> > Hi Pieter,
> >
> > Let me put change (1) into my own words. We are already computing affine
> > coordinates since we store public keys as the affine x-coordinate. It is
> > faster to compute is_even(y) than is_quadratic_residue(y) so we get a
> speed
> > up here during keypair generation. In the verification algorithm, we do
> the
> > following for the public key  x_only => affine + negate if not is_even(y)
> > => jacobian. The minor slowdown in verification comes from the extra
> > evenness check and possible negation which we didn't have to be done in
> the
> > previous version. This seems like a reasonable change if it makes things
> > easier for existing code bases and infrastructure.
> >
> > With change (2), I feel like including this auxiliary random data is
> > overkill for the spec. For me, the main point of the spec is the
> > verification algorithm which actually affects consensus. Providing a note
> > that non-deterministic signatures are preferable in many cases and here's
> > exactly how you should do that (hash then xor with private key) is
> > valuable. In the end, people will want several variations of the signing
> > algorithm anyway (e.g. pass in public key with secret key) so I think
> > specifying the most minimal way to produce a signature securely is the
> most
> > useful thing for this document.
> >
> > I feel similarly about hashing the public key to get the nonce. A note in
> > the alternative signing section that "if you pass the public key into
> > `sign` along with the secret key then you should do hash(bytes(d) ||
> > bytes(P) || m)" would suffice for me.
> >
> > Despite only being included in the alternative signing section, I it
> would
> > be nice to have a few of test vectors for these alternative methods
> anyway.
> > Perhaps they even deserve their own BIP?
> >
> > Cheers,
> >
> > LL
> >
> >
> > On Mon, Feb 24, 2020 at 3:26 PM Pieter Wuille via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> Hello list,
> >>
> >> Despite saying earlier that I expected no further semantical changes
> >> to BIP 340-342, I've just opened
> >> https://github.com/bitcoin/bips/pull/893 to make a number of small
> >> changes that I believe are still worth making.
> >>
> >> 1. Even public keys
> >>
> >> Only one change affects the validation rules: the Y coordinate of
> >> 32-byte public keys is changed from implicitly square to implicitly
> >> even. This makes signing slightly faster (in the microsecond range),
> >> though also verification negligibly slower (in the nanosecond range).
> >> It also simplifies integration with existing key generation
> >> infrastructure. For example BIP32 produces public keys with known
> >> even/oddness, but squaredness would need to be computed separately.
> >> Similar arguments hold for PSBT and probably many other things.
> >>
> >> Note that the Y coordinate of the internal R point in the signature
> >> remains implicitly square: for R the squaredness gives an actual
> >> performance gain at validation time, but this is not true for public
> >> keys. Conversely, for public keys integration with existing
> >> infrastructure matters, but R points are purely internal.
> >>
> >> This affects BIP 340 and 341.
> >>
> >> 2. Nonce generation
> >>
> >> All other semantical changes are around more secure nonce generation
> >> in BIP 340, dealing with various failure cases:
> >>
> >> * Since the public key signed for is included in the signature
> >> challenge hash, implementers will likely be eager to use precomputed
> >> values for these (otherwise an additional EC multiplication is
> >> necessary at signing time). If that public key data happens to be
> >> gathered from untrusted sources, it can lead to trivial leakage of the
> >> private key - something that Greg Maxwell started a discussion about
> >> on the moderncrypto curves list:
> >> https://moderncrypto.org/mail-archive/curves/2020/001012.html. We
> >> believe it should therefore be best practice to include the public key
> >> also in the nonce generation, which largely mitigates this problem.
> >>
> >> * To protect against fault injection attacks it is recommended to
> >> include actual signing-time randomness into the nonce generation
> >> process. This was mentioned already, but the update elaborates much
> >> more about this, and integrates this randomness into the standard
> >> signing process.
> >>
> >> * To protect against differential power analysis, a different way of
> >> mixing in this randomness is used (masking the private key completely
> >> with randomness before continuing, rather than hashing them together,
> >> which is known in the literature to be vulnerable to DPA in some
> >> scenarios).
> >>
> >> 3. New tagged hash tags
> >>
> >> To make sure that any code written for the earlier BIP text fails
> >> consistently, the tags used in the tagged hashes in BIP 340 are
> >> changed as well.
> >>
> >> What do people think?
> >>
> >> --
> >> Pieter
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; Correct, except that the speedup fro=
m is_even(y) over is_quadratic_residue(y) affects signing and not keypair g=
eneration.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Isn&#39;t this =
the same thing since in the spec it generates the public key in the signing=
 algorithm? If you pre-generate public key and pass it in there would be no=
 speedup to signing that I can see.<br></div><div><br></div><div>&gt; It&#3=
9;s not clear why removing these features from the spec would be an improve=
ment.</div><div><br></div><div>It could just be me but &quot;here&#39;s the=
 most minimal signing algorithm, you can add things in these ways to make i=
t more robust=C2=A0 in some settings&quot; is more intuitive than &quot;her=
e&#39;s the most robust signing algorithm, you can remove these things in t=
hese ways if they don&#39;t apply to your setting&quot;. I see your point t=
hat if it is likely to be misused then maybe the latter is preferable.<br><=
/div><div><br></div><div>LL</div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Feb 27, 2020 at 2:33 AM Jonas Nick &lt;<=
a href=3D"mailto:jonasdnick@gmail.com">jonasdnick@gmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Let me put =
change (1) into my own words.<br>
<br>
Correct, except that the speedup from is_even(y) over is_quadratic_residue(=
y)<br>
affects signing and not keypair generation.<br>
<br>
&gt; With change (2), I feel like including this auxiliary random data is o=
verkill<br>
&gt; for the spec. [...] I feel similarly about hashing the public key to g=
et the<br>
&gt; nonce.<br>
<br>
It&#39;s not clear why removing these features from the spec would be an im=
provement.<br>
The BIP follows a more reasonable approach: it specifies a reasonably secur=
e<br>
signing algorithm and provides the rationale behind the design choices. Thi=
s<br>
allows anyone to optimize for their use case if they choose to do so.<br>
Importantly, &quot;reasonably secure&quot; includes misuse resistance which=
 would be<br>
violated if the pubkey was not input to the nonce generation function.<br>
<br>
&gt; Perhaps they even deserve their own BIP?<br>
<br>
Yes, a standard for nonce exfiltration protection and MuSig would be import=
ant<br>
for compatibility across wallets.<br>
<br>
<br>
On 2/26/20 4:20 AM, Lloyd Fournier via bitcoin-dev wrote:<br>
&gt; Hi Pieter,<br>
&gt; <br>
&gt; Let me put change (1) into my own words. We are already computing affi=
ne<br>
&gt; coordinates since we store public keys as the affine x-coordinate. It =
is<br>
&gt; faster to compute is_even(y) than is_quadratic_residue(y) so we get a =
speed<br>
&gt; up here during keypair generation. In the verification algorithm, we d=
o the<br>
&gt; following for the public key=C2=A0 x_only =3D&gt; affine + negate if n=
ot is_even(y)<br>
&gt; =3D&gt; jacobian. The minor slowdown in verification comes from the ex=
tra<br>
&gt; evenness check and possible negation which we didn&#39;t have to be do=
ne in the<br>
&gt; previous version. This seems like a reasonable change if it makes thin=
gs<br>
&gt; easier for existing code bases and infrastructure.<br>
&gt; <br>
&gt; With change (2), I feel like including this auxiliary random data is<b=
r>
&gt; overkill for the spec. For me, the main point of the spec is the<br>
&gt; verification algorithm which actually affects consensus. Providing a n=
ote<br>
&gt; that non-deterministic signatures are preferable in many cases and her=
e&#39;s<br>
&gt; exactly how you should do that (hash then xor with private key) is<br>
&gt; valuable. In the end, people will want several variations of the signi=
ng<br>
&gt; algorithm anyway (e.g. pass in public key with secret key) so I think<=
br>
&gt; specifying the most minimal way to produce a signature securely is the=
 most<br>
&gt; useful thing for this document.<br>
&gt; <br>
&gt; I feel similarly about hashing the public key to get the nonce. A note=
 in<br>
&gt; the alternative signing section that &quot;if you pass the public key =
into<br>
&gt; `sign` along with the secret key then you should do hash(bytes(d) ||<b=
r>
&gt; bytes(P) || m)&quot; would suffice for me.<br>
&gt; <br>
&gt; Despite only being included in the alternative signing section, I it w=
ould<br>
&gt; be nice to have a few of test vectors for these alternative methods an=
yway.<br>
&gt; Perhaps they even deserve their own BIP?<br>
&gt; <br>
&gt; Cheers,<br>
&gt; <br>
&gt; LL<br>
&gt; <br>
&gt; <br>
&gt; On Mon, Feb 24, 2020 at 3:26 PM Pieter Wuille via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt;&gt; Hello list,<br>
&gt;&gt;<br>
&gt;&gt; Despite saying earlier that I expected no further semantical chang=
es<br>
&gt;&gt; to BIP 340-342, I&#39;ve just opened<br>
&gt;&gt; <a href=3D"https://github.com/bitcoin/bips/pull/893" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/893</a> to mak=
e a number of small<br>
&gt;&gt; changes that I believe are still worth making.<br>
&gt;&gt;<br>
&gt;&gt; 1. Even public keys<br>
&gt;&gt;<br>
&gt;&gt; Only one change affects the validation rules: the Y coordinate of<=
br>
&gt;&gt; 32-byte public keys is changed from implicitly square to implicitl=
y<br>
&gt;&gt; even. This makes signing slightly faster (in the microsecond range=
),<br>
&gt;&gt; though also verification negligibly slower (in the nanosecond rang=
e).<br>
&gt;&gt; It also simplifies integration with existing key generation<br>
&gt;&gt; infrastructure. For example BIP32 produces public keys with known<=
br>
&gt;&gt; even/oddness, but squaredness would need to be computed separately=
.<br>
&gt;&gt; Similar arguments hold for PSBT and probably many other things.<br=
>
&gt;&gt;<br>
&gt;&gt; Note that the Y coordinate of the internal R point in the signatur=
e<br>
&gt;&gt; remains implicitly square: for R the squaredness gives an actual<b=
r>
&gt;&gt; performance gain at validation time, but this is not true for publ=
ic<br>
&gt;&gt; keys. Conversely, for public keys integration with existing<br>
&gt;&gt; infrastructure matters, but R points are purely internal.<br>
&gt;&gt;<br>
&gt;&gt; This affects BIP 340 and 341.<br>
&gt;&gt;<br>
&gt;&gt; 2. Nonce generation<br>
&gt;&gt;<br>
&gt;&gt; All other semantical changes are around more secure nonce generati=
on<br>
&gt;&gt; in BIP 340, dealing with various failure cases:<br>
&gt;&gt;<br>
&gt;&gt; * Since the public key signed for is included in the signature<br>
&gt;&gt; challenge hash, implementers will likely be eager to use precomput=
ed<br>
&gt;&gt; values for these (otherwise an additional EC multiplication is<br>
&gt;&gt; necessary at signing time). If that public key data happens to be<=
br>
&gt;&gt; gathered from untrusted sources, it can lead to trivial leakage of=
 the<br>
&gt;&gt; private key - something that Greg Maxwell started a discussion abo=
ut<br>
&gt;&gt; on the moderncrypto curves list:<br>
&gt;&gt; <a href=3D"https://moderncrypto.org/mail-archive/curves/2020/00101=
2.html" rel=3D"noreferrer" target=3D"_blank">https://moderncrypto.org/mail-=
archive/curves/2020/001012.html</a>. We<br>
&gt;&gt; believe it should therefore be best practice to include the public=
 key<br>
&gt;&gt; also in the nonce generation, which largely mitigates this problem=
.<br>
&gt;&gt;<br>
&gt;&gt; * To protect against fault injection attacks it is recommended to<=
br>
&gt;&gt; include actual signing-time randomness into the nonce generation<b=
r>
&gt;&gt; process. This was mentioned already, but the update elaborates muc=
h<br>
&gt;&gt; more about this, and integrates this randomness into the standard<=
br>
&gt;&gt; signing process.<br>
&gt;&gt;<br>
&gt;&gt; * To protect against differential power analysis, a different way =
of<br>
&gt;&gt; mixing in this randomness is used (masking the private key complet=
ely<br>
&gt;&gt; with randomness before continuing, rather than hashing them togeth=
er,<br>
&gt;&gt; which is known in the literature to be vulnerable to DPA in some<b=
r>
&gt;&gt; scenarios).<br>
&gt;&gt;<br>
&gt;&gt; 3. New tagged hash tags<br>
&gt;&gt;<br>
&gt;&gt; To make sure that any code written for the earlier BIP text fails<=
br>
&gt;&gt; consistently, the tags used in the tagged hashes in BIP 340 are<br=
>
&gt;&gt; changed as well.<br>
&gt;&gt;<br>
&gt;&gt; What do people think?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Pieter<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
</blockquote></div></div>

--000000000000c014fe059f87881b--