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)
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
Precedence: list


--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--