summaryrefslogtreecommitdiff
path: root/0e/fcf418cbd7154137fb4cad873ce053a1f12675
blob: 66beebcefb07fff6e53677d333e64cfd9b8b477d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
Return-Path: <user@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E4B6BDA5;
	Fri,  4 Oct 2019 11:15:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com
	[62.13.148.98])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A321D3;
	Fri,  4 Oct 2019 11:15:43 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x94BFfJK064451;
	Fri, 4 Oct 2019 12:15:41 +0100 (BST)
	(envelope-from user@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id x94BFd4O057143
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Fri, 4 Oct 2019 12:15:40 +0100 (BST)
	(envelope-from user@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id A8D36401C5;
	Fri,  4 Oct 2019 11:15:38 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id BCE721FF74; Fri,  4 Oct 2019 07:15:36 -0400 (EDT)
Date: Fri, 4 Oct 2019 07:15:36 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy <jlrubin@mit.edu>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20191004111536.w7snbgpoe27xutfu@petertodd.org>
References: <87wodp7w9f.fsf@gmail.com>
	<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
	<CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
	<CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com>
	<C1OLL5FLxdOgfQ_A15mf88wIyztDapkyXJ2HZ0HxwmQADhRXGRe3le7Veso4tMIlbis6I0qiCd22xug5_GCKtgrjGnBtojWxOCMgn1UldkE=@protonmail.com>
	<CAEM=y+WCGSF_=WXpgXJUZCZcGUQhxzXF6Wv1_iX+VwEyYSWypg@mail.gmail.com>
	<CAD5xwhi7=5eiv1jjf72-rUezZMfj3caR+PGfZEa8i8rjNjodFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6xqe2bg75y77lfnd"
Content-Disposition: inline
In-Reply-To: <CAD5xwhi7=5eiv1jjf72-rUezZMfj3caR+PGfZEa8i8rjNjodFg@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Server-Quench: 4cc2f775-e698-11e9-b106-8434971169dc
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	bgdMdgYUF1YAAgsB Am8bWlZeUVh7XWM7 bghPaBtcak9QXgdq
	T0pMXVMcXAxsc2pV AmEeVx5zcwYIeXly ZU4sWiMIXhJ9ckNg
	F0hdHXAHZDJpdTIe UEZFfwdXdApNfx5D YwQsGhFYa3VsNCMk
	FAgyOXU9MCtqYBdx Qw4NMVQTR0lOEjMi clglJQIENHFNWCwo
	ZyYreBY3G0ANM0Mv MF0uEU4YPn1aBgxF FFxWGy5eIREITS02
	EUtcWk8YCCBBCWAU Cxs5OgVFHDtPRkIA 
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: "lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the
 discussion about noinput / anyprevout
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Fri, 04 Oct 2019 11:15:45 -0000


--6xqe2bg75y77lfnd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:
> Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> function to allow concatenation of an unlimited amount of data, provided
> the only use is to hash it.
>=20
> You can then use it perhaps as follows:
>=20
> // start a new hash with item
> OP_SHA256STREAM  (-1) -> [state]
> // Add item to the hash in state
> OP_SHA256STREAM n [item] [state] -> [state]
> // Finalize
> OP_SHA256STREAM (-2) [state] -> [Hash]
>=20
> <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3> <3> OP_SHA256STREAM <-=
2>
> OP_SHA256STREAM

One issue with this is the simplest implementation where the state is just =
raw
bytes would expose raw SHA256 midstates, allowing people to use them direct=
ly;
preventing that would require adding types to the stack. Specifically I cou=
ld
write a script that rather than initializing the state correctly from the
official IV, instead takes an untrusted state as input.

SHA256 isn't designed to be used in situations where adversaries control the
initialization vector. I personally don't know one way or the other if anyo=
ne
has analyzed this in detail, but I'd be surprised if that's secure. I
considered adding midstate support to OpenTimestamps but decided against it=
 for
exactly that reason.

I don't have the link handy but there's even an example of an experienced
cryptographer on this very list (bitcoin-dev) proposing a design that falls
victim to this attack. It's a subtle issue and we probably don't want to
encourage it.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--6xqe2bg75y77lfnd
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAl2XKdUACgkQLly11TVR
LzfKEhAAptWwKsyI+NYMa5ua2sv4J/s82vDkwkcolSPDLrViYJXTWG2GIwINILcQ
I147uxVLzMbBeftW6IE6w2b8kuN6p+H919w5xosCGMz1hrvdqfzVSgzDAEEbGob0
W2MTyUFkTyUVbEjtzyYge+JEFefXdRU8FEJL3ixO9wT2AhYViFlifxP9jiuryUb6
VMxmW74zc9M8kJDETDvTVkhnGUBpRTRhnfeUm2d1AdUt2eNcARU4UsPwes38iPse
l5n94mfBCplkgpowyoaAD5bVMD0WGVuGjDXn7EH8GP8yhrfXkPfl79KB3P1JrbVl
jhhdfO/0Kq7E4b2rvC8zRPjjQYOpLWIZze5x2ol+StcJu2ZBLXMSsEOSN8nPGFXz
r/Lr/qqtTfUBZYniYnt9FfONfggJyJjqK4SrxDMuLgeEJB0pRIewj2d9PhieYLNv
D24a0QYNvRuKd0pc/CYv/QUOtEogC+m/Q9M0cTQQdZB0FgIeDo3eHgtN3exE+51Y
UMx0pLSh/dcOqgRIdpNOEmqvggMl49dJRKU5YXEq45dGiP1TQqzQQwb90dwT7fWg
8XToKnYgByFuYs3ib1Bg2wZ/ZYzvVRuUoUgCPNOoFXWuwVM6NhdGVuHNREIbjTzN
hiF5cSVu0UiIKQYg7koKXHvcU0J240hlRWamlet91TpuBLPW1YY=
=67vT
-----END PGP SIGNATURE-----

--6xqe2bg75y77lfnd--