From: "Russell O'Connor" <roconnor@blockstream•com>
To: Tim Ruffing <crypto@timruffing•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
Date: Sat, 21 Mar 2020 12:59:47 -0400 [thread overview]
Message-ID: <CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com> (raw)
In-Reply-To: <de7bd393327015a5b97ffff0d15a7c90d2d2196a.camel@timruffing.de>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1588 bytes --]
next prev parent reply other threads:[~2020-03-21 17:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 21:35 Pieter Wuille
2020-03-21 13:34 ` Tim Ruffing
2020-03-21 16:59 ` Russell O'Connor [this message]
2020-03-22 9:43 ` Tim Ruffing
2020-03-22 15:30 ` Russell O'Connor
2020-03-22 15:38 ` Tim Ruffing
2020-03-21 20:29 ` Marko Bencun
2020-03-23 14:38 ` Dustin Dettmer
2020-03-24 7:49 ` Tim Ruffing
2020-03-24 14:51 ` Dustin Dettmer
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='CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=crypto@timruffing$(echo .)de \
/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