From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6D0D2C0177 for ; Mon, 23 Mar 2020 14:38:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 68A9988012 for ; Mon, 23 Mar 2020 14:38:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCuShHuni4Xh for ; Mon, 23 Mar 2020 14:38:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by hemlock.osuosl.org (Postfix) with ESMTPS id C334B87FA4 for ; Mon, 23 Mar 2020 14:38:58 +0000 (UTC) Received: by mail-ot1-f52.google.com with SMTP id l23so3493805otf.3 for ; Mon, 23 Mar 2020 07:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E8OaCCpEMlxl5SN0tjz4mTpmM0kwDE5EqtXrc5D322E=; b=p/fJhcDpzqIoI+lmPqZm0mAFF+AuJsTdH/vM1EYjqPs4pl8qntNwowSyY2uoSDbBGr miB6X1mobrEWf/4ysQsmhhHz7VrcWp18WIrnmbkj5W0x/aQzFIFJA5/HXJszCMVUm2QU UhmYd9jRS+DQ6clO4s+6a7l64KMpmVQ0aamDwq5B4/w/2xCEbUVETHzYYuHIg4ez/8MW NzP2iJGzQX08xX2pFLQ/y/cquqN3ceydFjNWd8CxbvwahhvOihJCnVXe3mbH8WzYet+S 9wch6fyll0ry9GTej4A25HkFzFrPrNAaE3qFQ9QCwTd7Dpjsc+ucCyIhXv3rn0yjivvb mkKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=E8OaCCpEMlxl5SN0tjz4mTpmM0kwDE5EqtXrc5D322E=; b=tJP0Pmsq3ogO7r0j3OlncYh/7Z0RFd+EXVgpudd0pxhYbNuRlp3ifIrt5kp30IYjOw CoOE6bglBxNlkxIl6f1osszWR3l5BDqwvefymwVmx4sw3Vfri3FJe+l82NqfKdoeMedf xnvYysr1nhHYN2g99rX50wbHY1Ni8IX5HrJ5HEQ2owKWTkZBjW0A5f8HY/BT9IMjEQbV yi4dm5W2a2Az0u/AvKW39elQd7Aw3z8PJ6VxS0LHNRrVwQIbyd8c+34vmY6SUpjXHEmi e79ipsB0SpHlElXzQbEKahMZby8LoKvYmTg2n2lzD7drnVm6mJl8r2gyZQrztOX4/ACt 7tVw== X-Gm-Message-State: ANhLgQ36Yl3jWKUsKpDLjzdxWjSijbQZFNvSZD7iggIFpOTOs4UgCgmx ZFGt08scPlmX8cuA8V2FAOQuhDA/amjdrnzX7xC3VoNd X-Google-Smtp-Source: ADFU+vuV7zCbrCIq2FgjDKpmNPQcq6b9wtladb5URruSc4xqvRgd+8LVNuVZQ14sjgxCJvtGsdCyGMETJewXKf56Ysk= X-Received: by 2002:a05:6830:1d52:: with SMTP id p18mr18926634oth.204.1584974337468; Mon, 23 Mar 2020 07:38:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dustin Dettmer Date: Mon, 23 Mar 2020 07:38:45 -0700 Message-ID: To: Bitcoin Protocol Discussion , Pieter Wuille Content-Type: multipart/alternative; boundary="0000000000005cf09105a1869817" X-Mailman-Approved-At: Mon, 23 Mar 2020 15:06:18 +0000 Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 14:38:59 -0000 --0000000000005cf09105a1869817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t be stopped, splitting the SW o= ver 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. --0000000000005cf09105a1869817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent write up, thanks for putting it together.<= /div>

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 c= an=E2=80=99t 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 y= our storage solution (whatever it may be), export the xpub(s) and verify th= e receiving addresses match xpubs with external software before receiving.<= /div>
2) Generate and export withdrawal transactions offli= ne
3) Verify transactions against the same xpub(s) u= sing external software
4) Upload transactions
<= div dir=3D"auto">
This mitigates, I believe, all= leak vectors besides k/R hacking and prechosen entropy.

I made an external tool to just that here:= =C2=A0

Would love to add k commitments when (if?) we settle on best pr= actices for it.
--0000000000005cf09105a1869817--