{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-04\n📝 Original message:On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:\n\u003e Awhile back, Ethan and I discussed having, rather than OP_CAT, an\n\u003e OP_SHA256STREAM that uses the streaming properties of a SHA256 hash\n\u003e function to allow concatenation of an unlimited amount of data, provided\n\u003e the only use is to hash it.\n\u003e \n\u003e You can then use it perhaps as follows:\n\u003e \n\u003e // start a new hash with item\n\u003e OP_SHA256STREAM  (-1) -\u003e [state]\n\u003e // Add item to the hash in state\n\u003e OP_SHA256STREAM n [item] [state] -\u003e [state]\n\u003e // Finalize\n\u003e OP_SHA256STREAM (-2) [state] -\u003e [Hash]\n\u003e \n\u003e \u003c-1\u003e OP_SHA256STREAM \u003ctag\u003e \u003csubnode 2\u003e \u003csubnode 3\u003e \u003c3\u003e OP_SHA256STREAM \u003c-2\u003e\n\u003e OP_SHA256STREAM\n\nOne issue with this is the simplest implementation where the state is just raw\nbytes would expose raw SHA256 midstates, allowing people to use them directly;\npreventing that would require adding types to the stack. Specifically I could\nwrite a script that rather than initializing the state correctly from the\nofficial IV, instead takes an untrusted state as input.\n\nSHA256 isn't designed to be used in situations where adversaries control the\ninitialization vector. I personally don't know one way or the other if anyone\nhas analyzed this in detail, but I'd be surprised if that's secure. I\nconsidered adding midstate support to OpenTimestamps but decided against it for\nexactly that reason.\n\nI don't have the link handy but there's even an example of an experienced\ncryptographer on this very list (bitcoin-dev) proposing a design that falls\nvictim to this attack. It's a subtle issue and we probably don't want to\nencourage it.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/9c383745/attachment.sig\u003e"}