From: Dustin Dettmer <dustinpaystaxes@gmail•com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Pieter Wuille <bitcoin-dev@wuille•net>
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
Date: Mon, 23 Mar 2020 07:38:45 -0700 [thread overview]
Message-ID: <CABLeJxQsse99aw35DxSDOyVTruFCgi0hmZntvgbYtPLSRGQ+xA@mail.gmail.com> (raw)
In-Reply-To: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
Excellent write up, thanks for putting it together.
On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:
> When both the HW and the SW are compromised, clearly no security is
> possible,
> as all entities are controlled by the same party in that case.
>
While all SW being compromised can’t be stopped, splitting the SW over two
stages can dramatically increase your security if both HW & SW are
compromised. You can do that by:
1) When you setup your storage solution (whatever it may be), export the
xpub(s) and verify the receiving addresses match xpubs with external
software before receiving.
2) Generate and export withdrawal transactions offline
3) Verify transactions against the same xpub(s) using external software
4) Upload transactions
This mitigates, I believe, all leak vectors besides k/R hacking and
prechosen entropy.
I made an external tool to just that here:
https://github.com/koinkeep/gatekeeper
Would love to add k commitments when (if?) we settle on best practices for
it.
[-- Attachment #2: Type: text/html, Size: 1574 bytes --]
next prev parent reply other threads:[~2020-03-23 14:38 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
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 [this message]
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=CABLeJxQsse99aw35DxSDOyVTruFCgi0hmZntvgbYtPLSRGQ+xA@mail.gmail.com \
--to=dustinpaystaxes@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/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