From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 To: Jeremy , Bitcoin Protocol Discussion Message-ID: <20191004111536.w7snbgpoe27xutfu@petertodd.org> References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6xqe2bg75y77lfnd" Content-Disposition: inline In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 <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--