From: "Russell O'Connor" <roconnor@blockstream•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Fwd: BIP 340 updates: even pubkeys, more secure nonce generation
Date: Tue, 25 Feb 2020 22:26:42 -0500 [thread overview]
Message-ID: <CAMZUoK=RDkNZM=hSZu2OMoH1y=nrx57weefu1ow8ZnX7wSOErw@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkAebw6VzSco3F+wnLptNwsCiEw23t2pLj0xitiOSszMQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 2. Nonce generation
>
> All other semantical changes are around more secure nonce generation
> in BIP 340, dealing with various failure cases:
>
> * 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.
>
I do worry that standardizing on a non-deterministic nonce generation
scheme makes the problem of private key exfiltration a much bigger concern
in the application of hardware signing devices.
While sorely imperfect, with a deterministic nonce scheme, we at least have
the option of spot checking hardware devices to see if they are producing
signatures in accordance with their specified nonce scheme. But short of
providing some kind of certificate, we won't be able to do such checks
against hardware devices that use the proposed synthetic nonce. (Question:
can a hardware device safely output the random value 'a' it used its
"certificate"? AFAIU 'a' is not considered secret data; it just needs to
be not under attacker control. Should hardware wallets be encouraged to
return this value?)
The best way to mitigate this is to use the Nonce exfiltration protection
mentioned; however there are no references on how to do this. Ideally we'd
standardize this Nonce exfiltration protection scheme within this synthetic
nonce scheme. However, I don't think it is worth holding this BIP up on
that; it seems reasonable to introduce a new section to this BIP addressing
that problem in the future. Maybe instead we can get references to more
information about this Nonce exfiltration protection that is mentioned?
Really I just want to do whatever we reasonably can do to avoid a world
where we end up providing hardware signing devices with a hard to detect
underhanded communications channel.
[-- Attachment #2: Type: text/html, Size: 2544 bytes --]
next prev parent reply other threads:[~2020-02-26 3:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 4:26 [bitcoin-dev] " Pieter Wuille
[not found] ` <CAMZUoKkAebw6VzSco3F+wnLptNwsCiEw23t2pLj0xitiOSszMQ@mail.gmail.com>
2020-02-26 3:26 ` Russell O'Connor [this message]
2020-02-26 4:20 ` Lloyd Fournier
2020-02-26 15:34 ` Jonas Nick
2020-02-27 4:55 ` Lloyd Fournier
2020-03-22 5:51 ` Lloyd Fournier
2020-03-03 11:29 [bitcoin-dev] Fwd: " Marko
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='CAMZUoK=RDkNZM=hSZu2OMoH1y=nrx57weefu1ow8ZnX7wSOErw@mail.gmail.com' \
--to=roconnor@blockstream$(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