From: Tim Ruffing <crypto@timruffing•de>
To: Marko Bencun <mbencun@gmail•com>,
Russell O'Connor <roconnor@blockstream•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
Date: Sun, 22 Mar 2020 10:43:12 +0100 [thread overview]
Message-ID: <c14db3d600c0c60bbf06ea832fc438a5c9fd97da.camel@timruffing.de> (raw)
In-Reply-To: <CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com>
On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> 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.
If spot checking means checking a few instances, then I think this is a
pretty weak defense. What if the device starts to behave differently
after a year?
On Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:
> Practically speaking, most hardware wallets allow you to import your
> own BIP39 seed, so you can work around key generation attacks today,
> with a one time inconvenience at the start. However, with the signing
> nonce attacks, a user today has no protection.
>
How do you know that the device really uses your seed? This can only be
done by comparing the public keys output by the HW with a second
computation. Even if you use only non-hardened derivation, you need to
check the master (root) public key and that means you need compute the
master root public key once from the seed. You can't do this manually
on a sheet of paper after you rolled a few dice to generate your seed.
So you need to store the seed on a second device (if only for a short
time). And I think this defeats the purpose of a HW wallet.
And even if assume that spot checking and importing the seed works, the
problem is not solved. We still need a clearly specified full protocol
that we can analyze.
Best,
Tim
next prev parent reply other threads:[~2020-03-22 9:43 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
2020-03-22 9:43 ` Tim Ruffing [this message]
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=c14db3d600c0c60bbf06ea832fc438a5c9fd97da.camel@timruffing.de \
--to=crypto@timruffing$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mbencun@gmail$(echo .)com \
--cc=roconnor@blockstream$(echo .)com \
/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