path: root/43/c492a2703e99ee617a04d4d9734da7c75904d9

Return-Path: <dp@simplexum.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 05B3FC0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 20:22:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id E897885EA4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 20:22:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Xi6IEvSS98Wr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 20:22:37 +0000 (UTC)
X-Greylist: delayed 00:06:28 by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 9E37985E35
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 20:22:37 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
 by mail.ruggedbytes.com (Postfix) with ESMTPS id 576422600175;
 Sat, 11 Jan 2020 20:16:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
 s=mail; t=1578773766;
 bh=KDOQLzpfh8fdccJKg0UXTP+O1uyoxXqCVD1tOA5OipM=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References;
 b=TTeiTY9IdBaAMV9l5n8eEGsXuapxM8/xQgrWGe5tXcDtnraCB3e1SOWBYJsqblezL
 vOdT+VvJRIHuamILydlaZ1fIEs4WCJzzj62UGHDGOIAvAXbgGic7tOBbO7YzSACJlf
 GvZAf6Bj0TU0FEjwk2/8yg+nvi0H8f7HefqhwENQ=
Date: Sun, 12 Jan 2020 01:17:05 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: "Peter D. Gray via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200112011705.6f6102dd@simplexum.com>
In-Reply-To: <20200111172906.GO10797@coinkite.com>
References: <20200111172906.GO10797@coinkite.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/vS.KszeHYkG/=qf.8zV=6kw";
 protocol="application/pgp-signature"; micalg=pgp-sha256
X-Mailman-Approved-At: Sat, 11 Jan 2020 20:28:53 +0000
Cc: Peter Gray <peter@coinkite.com>
Subject: Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating
 source/output PSBT files
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2020 20:22:39 -0000

--Sig_/vS.KszeHYkG/=qf.8zV=6kw
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

I am not sure that this particular task should be done with data
embedded in PSBT itself, and not with some sort of container that
includes PSBT and the authentication information.

The benefit seems to be in reusing PSBT structure for compatibilty, and
this might be a valid way, although I do not agree with some of your
points. I elaborate below:

> 1) In the PSBT globals section, a signature over the "source" PSBT
> file. It would cover all the bytes of the original PSBT file, as
> it was received by the Signer.

The problem of authenticating the contents of PSBT is independent of
the signing action. PSBT might be altered on the path from Creator to
Signer. Therefore you cannot always say that Signer will be an
authority over 'correctness' of PSBT.

> - At the end of the signing process, the Finalizer should check all
> the Signers have worked from the same PSBT file (assuming that's
> the flow expected)

If there is MitM, checking something at Finalizer is likely too
late - the party that can intercept PSBTs can finalize before the
legitimate Finalizer and broadcast the transaction.

Participants can work from the same PSBT file if they all receive the
same PSBT, and not working in chain where next particpant receives
updated PSBT from the previous participant. Otherwise they will need to
either pass two files (original and updated), or work out which fields
(key-value blobs) to remove to get the 'source' PSBT (which might not be
trivial with presense of proprietary and unknown fields). Even if you
know which key-value pairs to remove, there is no requirement for
ordering of the fields, and some signer can serialize them in different
order after dserialize/sign/add-signatures/re-serialize operation.

Introducing additional ordering or other structure requirements over
simple key-value structure will add complexity to PSBT processing, and
adding complexity on such a basic level should have really serious
reasons, because that increases effort required for even basic
implementations and increases chance of bugs.

If there is some authority on the 'correctness' of 'original' PSBT
(all particpants receive same PSBT at the start), particpants should
check the signature by that authority. That authority might use
the key used only for authentication, and not in the tx signing.

If particpants send PSBT in chain after adding their signatures, then
each participant can add their signature to say 'the contents
of PSBT after my updates should match this hash'.

The signatures of previous participants in the chain most likely do not
matter because of difficulty of restoring the contents of PSBT as it
was before the previous particpant, if you do not pass _all_ the PSBTs
(which is excessive).=20
=20
> 2) In the output section, specifically, the last key/value pair of
> the last output of the transaction, I want to add a similar signature,
> again signed by one of the keys used in the signing process. This
> signature will cover all the bytes of the resulting (signed) PSBT
> up to that point. Because it is the last output of the output
> section, that signature will be the last few bytes of the PSBT file.
> By "appending" the signature in this way, it's easier to validate
> and create the signature, without blanking the signature area during
> digest step.

This will introduce unnecessary higher-level structure to PSBT for the
reasons that I do not find strong enough for the amount of complexity
added.

Also, as I said above, you likely do not need more than one
signature - if this is 'fan-out' scheme, then participants need do
check the sig of authority that created PSBT; if this is piggy-back
chain, then only previous particpant's signature is easily verifiable.

> ## Next Steps
>=20
> I'd like to get two officially-assigned BIP-174 key numbers assigned
> for these two signatures, and then I will see that it gets added
> into Coldcard's firmware immediately. In time, other tools are
> welcome to take advantage of these checks. I will also write a BIP
> for this, and/or make an addition to BIP-174.

I think you do not need to wait for officially-assigned key numbers,
and can just implement the scheme you envision with proprietary keys,
document and promote it. Then if it shows its usefulness, it will
either become de-facto standard with your proprietary keys (and
everyone will want to support 'Coldard PSBT auth' or whatever the name),
or the scheme will have serious grounds to be converted to standard and
have non-proprietary keys assigned.

// Dmitry.

--Sig_/vS.KszeHYkG/=qf.8zV=6kw
Content-Type: application/pgp-signature
Content-Description: Цифровая подпись OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEsXo1u6GHOVeE4qazIwHSa9wVFg0FAl4aLUEACgkQIwHSa9wV
Fg3ZTxAAkWw8W/aU6wF9h+RXnTFTjgxpDrGnbuta/wWp69kof7VP3uLNvjLQsHYo
1GSAYSsOMx5sjCueqKgjMP3uNz02+2cToRyX8JAlrGH2zJFZpBDBgD7xfHP/hXKL
qADfdjHxaaKRRaw1JaeIftIQVFDtp/v501o5QbdYWZkr+txR1CDbdRpkpTxcmc1U
/NhxdUxOD06GsPBPNblJHFxpBm+zOT5LuhIkzGzumlSLQgGR0thUpD+IpKJdDG+j
LDAU7KrDksjPQhXUyIHnQxmdE/cGmLAxOe+28bv8vhH/aZdizlox/hAcF797iRzi
ZXnKVzC0WPQkM1OwkR+/UbP6i4/td9oPqBkc6f8jOXfzn1hm42a+r3zUw3FV2Wpk
LBNuc7x3rbRWlUGa2uf0tFyvew7othy7wbHEz46hANiqDc5G5QheQVvKZlEeZwLx
OW5YVR6/wXS0Bj8tfIsZgYm59SEV4HbftJ1GRqTJ7YKuiC2GcgTaOuvr85I0BHyK
qleR3R6xgnC2x2YukRl46Qw/YAtKjWogv/sVXN/MK8NzG04XByAuQu+OPV5AR+wI
2tgiVejTTETgP/lBRkSbqsQOI+TmXADVueseNIb4oSyjIizancQE9RZEbDO+Bvdg
ZBOF1+Foai3Vs7mYWYvamZ/tMhizIz3EQyWVzMGZp+klfLdAicM=
=Lfdy
-----END PGP SIGNATURE-----

--Sig_/vS.KszeHYkG/=qf.8zV=6kw--