public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [bitcoin-dev] Overview of anti-covert-channel signing techniques 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@wuille.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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