From: Stepan Snigirev <snigirev.stepan@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
Date: Fri, 28 Feb 2020 15:40:21 +0100 [thread overview]
Message-ID: <CACL8y1sgMDMZpnfa86sRpejSdO3ieVKGvq3NqZ+oe0wr6tk1kw@mail.gmail.com> (raw)
In-Reply-To: <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1947 bytes --]
next prev parent reply other threads:[~2020-02-28 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 2:59 Stepan Snigirev
2020-02-28 13:31 ` ZmnSCPxj
2020-02-28 14:40 ` Stepan Snigirev [this message]
2020-02-28 17:42 ` Marko
2020-03-02 19:45 ` Dustin Dettmer
2020-03-02 20:01 ` Dustin Dettmer
2020-02-27 3:26 freedom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACL8y1sgMDMZpnfa86sRpejSdO3ieVKGvq3NqZ+oe0wr6tk1kw@mail.gmail.com \
--to=snigirev.stepan@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox