diff options
| author | Stepan Snigirev <snigirev.stepan@gmail.com> | 2020-02-28 15:40:21 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-02-28 14:41:04 +0000 |
| commit | 8ac3d639e5bd0686e1e93cafcab772f6bfc35d5d (patch) | |
| tree | 17fc215d3e28e6a63c7f448545490c3d00cf247d | |
| parent | 1739ca93803249f73327cfe6b97e4a0a5843aed2 (diff) | |
| download | pi-bitcoindev-8ac3d639e5bd0686e1e93cafcab772f6bfc35d5d.tar.gz pi-bitcoindev-8ac3d639e5bd0686e1e93cafcab772f6bfc35d5d.zip | |
Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
| -rw-r--r-- | a9/1d416dede76be99eb509a95f95f19df7dbbb52 | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/a9/1d416dede76be99eb509a95f95f19df7dbbb52 b/a9/1d416dede76be99eb509a95f95f19df7dbbb52 new file mode 100644 index 000000000..0637b936c --- /dev/null +++ b/a9/1d416dede76be99eb509a95f95f19df7dbbb52 @@ -0,0 +1,150 @@ +Return-Path: <snigirev.stepan@gmail.com> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 31514C0177 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 14:41:04 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by fraxinus.osuosl.org (Postfix) with ESMTP id 206B885F79 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 14:41:04 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from fraxinus.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id paH7FaJzP_JQ + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 14:41:03 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com + [209.85.210.44]) + by fraxinus.osuosl.org (Postfix) with ESMTPS id 74B1C85F0A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 14:41:03 +0000 (UTC) +Received: by mail-ot1-f44.google.com with SMTP id h9so2729789otj.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 06:41:03 -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=L1+n4/oSFNcBz10NwWr9QxNv7gs0U6imeEW/jZP0sHw=; + b=SZ/rSfGO96I42DS3hlcojeSZaeJkQQu6wrc9/jPOctqtFB99Zez8o/Cs7tEFgrdzFf + 2pisgXjRDpRct0BXo2ams1UPNA+aI3yJ0ESp2W7B9B8b2fpXofFyeGTbdL4+c+dLYAKP + 51Og4O6a7SfpZ4QxeuKY+qaIuIHUn3p6i1+uo0ksVcNep0nN7IeOIxiJjNRv9AUXh4lh + amt0si/CxWjnJvvyfQ+InQbKD9v8esmyUax3afh1CAfntXwgYqUmav/HR5eh6UCGZIHc + kBMytNgjfRLrfHt3y+37zb0FqbVNaYiLdvtCxAIg2RfqpyA+D7FvKmKtwmBymfCHHthq + SuJg== +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=L1+n4/oSFNcBz10NwWr9QxNv7gs0U6imeEW/jZP0sHw=; + b=SYolDY22+f+qeySfOuUM1Xjr9vVCjRGcHU8+FtxLpE84VpyibgMq5Ym31iZNhphRno + GvU5GgwbCtfEkTZMAPvv01j5+dpKERiH1PFcXdb7c2mreIUbeoI6jX8dHqW6pcbw99Yd + j8la1wjdfQEZ+XcQioLgCPDBJgYBwLmvw1+Ehwi2yLPs9qZdUAQ5mQFOejps3hFt9p9t + VDh1XNGEwJNeR1rTavsterwZwGTvnhyiHOAsnnRW/YleQQXRSczxwGswD79S38uLPdzu + W7E3a46L1eqy7WT8uaQBcy6iqZLLBPcHr738HZ4pvbOKRIttCF4QQ25eiFzYQToEHSiI + ZJTg== +X-Gm-Message-State: APjAAAWTVdq2bG+37zY6T+O/vZTFawBnVE/9YHVAsJDIJGy8wItwz8us + RsLq8H+7c/N2RsCiken8DDmNpgJYq1/J25fiing= +X-Google-Smtp-Source: APXvYqycqU2d1Dsx+23tFG54Ayk9anvBFEej02DKYm3Chh3402A4glUt3WqRL0/5KH+InveDDFJUotp1wrhm/vQUo8A= +X-Received: by 2002:a05:6830:9a:: with SMTP id + a26mr3632417oto.273.1582900861691; + Fri, 28 Feb 2020 06:41:01 -0800 (PST) +MIME-Version: 1.0 +References: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.com> + <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com> +In-Reply-To: <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com> +From: Stepan Snigirev <snigirev.stepan@gmail.com> +Date: Fri, 28 Feb 2020 15:40:21 +0100 +Message-ID: <CACL8y1sgMDMZpnfa86sRpejSdO3ieVKGvq3NqZ+oe0wr6tk1kw@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="000000000000936c8e059fa3d3e0" +X-Mailman-Approved-At: Fri, 28 Feb 2020 14:44:16 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and + airgapped signers +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: Fri, 28 Feb 2020 14:41:04 -0000 + +--000000000000936c8e059fa3d3e0 +Content-Type: text/plain; charset="UTF-8" + +Dear ZmnSCPxj, + +> I think it would be unsafe to use a deterministic scheme, that takes as +input the message m and the privkey only. + +Yes, using only the message and the private key is unsafe. Signer should +use all the data coming from the host, so f(sha256(n), m, privkey) is a +good candidate. If more than one blinding factor is sent - all of them +should be used as well. + +> Otherwise a completely-random `k` would be much better, but the signer +might not have enough resources to gather sufficient entropy. + +I am not a big fan of pure RNG-generated nonces, so I would suggest to use +this entropy only as additional data for a deterministic scheme. +For example, Yubikey had a problem with RNG initialization that caused +leakage of the private key [1]. +If the signer has any source of entropy, even if it is not a very good one, +the entropy from this source can be mixed into the nonce generation +function: +f(sha256(n),m,privkey,entropy). + +Another issue is that deterministic nonce generation is vulnerable to +glitch attacks - if I ask the wallet to sign the same message twice but +after nonce generation I glitch and flip a bit in the message, I will get +two signatures with the same nonce but with different messages - from these +signatures I can calculate the private key. +So I would recommend to include a monotonic counter into the nonce +generation function as well: f(sha256(n), m, privkey, entropy, counter) +As usual, counter should be increased _before_ signing. + +Ref: [1] +https://www.yubico.com/support/security-advisories/ysa-2019-02/#technical-details + +Best, +Stepan + +--000000000000936c8e059fa3d3e0 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Dear ZmnSCPxj,</div><div><br></div><div>>=C2=A0I t= +hink it would be unsafe to use a deterministic scheme, that takes as input = +the message m and the privkey only.</div><div><br></div><div>Yes, using onl= +y the message and the private key is unsafe. Signer should use all the data= + coming from the host, so f(sha256(n), m, privkey) is a good candidate. If = +more than one blinding factor is sent - all of them should be used as well.= +</div><div><br></div><div>>=C2=A0Otherwise a completely-random `k` would= + be much better, but the signer might not have enough resources to gather s= +ufficient entropy.</div><div><br></div><div>I am not a big fan of pure RNG-= +generated nonces, so I would suggest to use this entropy only as additional= + data for a deterministic scheme.</div><div>For example, Yubikey had a prob= +lem with RNG initialization that caused leakage of the private key [1].</di= +v><div>If the signer has any source of entropy, even if it is not a very go= +od one, the entropy from this source can be mixed into the nonce generation= + function:</div><div>f(sha256(n),m,privkey,entropy).</div><div><br></div><d= +iv>Another issue is that deterministic nonce generation is vulnerable to gl= +itch attacks - if I ask the wallet to sign the same message twice but after= + nonce generation I glitch and flip a bit in the message, I will get two s= +ignatures with the same nonce but with different messages - from these sign= +atures I can calculate the private key.=C2=A0</div><div>So I would recommen= +d to include a monotonic counter into the nonce generation function as well= +:=C2=A0f(sha256(n), m, privkey, entropy, counter)</div><div>As usual, count= +er should be increased _before_ signing.</div><div><br></div><div>Ref: [1]= +=C2=A0<a href=3D"https://www.yubico.com/support/security-advisories/ysa-201= +9-02/#technical-details">https://www.yubico.com/support/security-advisories= +/ysa-2019-02/#technical-details</a></div><div><br></div><div>Best,</div><di= +v>Stepan</div></div> + +--000000000000936c8e059fa3d3e0-- + |