{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-04\n📝 Original message:Interesting point.\n\nThe script is under your control, so you should be able to ensure that you\nare always using a correctly constructed midstate, e.g., something like:\n\nscriptPubKey: \u003c-1\u003e OP_SHA256STREAM DEPTH OP_SHA256STREAM \u003c-2\u003e\nOP_SHA256STREAM\n\u003chash\u003e OP_EQUALVERIFY\n\nwould hash all the elements on the stack and compare to a known hash.\nHow is that sort of thing weak to midstateattacks?\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Fri, Oct 4, 2019 at 4:16 AM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:\n\u003e \u003e Awhile back, Ethan and I discussed having, rather than OP_CAT, an\n\u003e \u003e OP_SHA256STREAM that uses the streaming properties of a SHA256 hash\n\u003e \u003e function to allow concatenation of an unlimited amount of data, provided\n\u003e \u003e the only use is to hash it.\n\u003e \u003e\n\u003e \u003e You can then use it perhaps as follows:\n\u003e \u003e\n\u003e \u003e // start a new hash with item\n\u003e \u003e OP_SHA256STREAM  (-1) -\u003e [state]\n\u003e \u003e // Add item to the hash in state\n\u003e \u003e OP_SHA256STREAM n [item] [state] -\u003e [state]\n\u003e \u003e // Finalize\n\u003e \u003e OP_SHA256STREAM (-2) [state] -\u003e [Hash]\n\u003e \u003e\n\u003e \u003e \u003c-1\u003e OP_SHA256STREAM \u003ctag\u003e \u003csubnode 2\u003e \u003csubnode 3\u003e \u003c3\u003e OP_SHA256STREAM\n\u003e \u003c-2\u003e\n\u003e \u003e OP_SHA256STREAM\n\u003e\n\u003e One issue with this is the simplest implementation where the state is just\n\u003e raw\n\u003e bytes would expose raw SHA256 midstates, allowing people to use them\n\u003e directly;\n\u003e preventing that would require adding types to the stack. Specifically I\n\u003e could\n\u003e write a script that rather than initializing the state correctly from the\n\u003e official IV, instead takes an untrusted state as input.\n\u003e\n\u003e SHA256 isn't designed to be used in situations where adversaries control\n\u003e the\n\u003e initialization vector. I personally don't know one way or the other if\n\u003e anyone\n\u003e has analyzed this in detail, but I'd be surprised if that's secure. I\n\u003e considered adding midstate support to OpenTimestamps but decided against\n\u003e it for\n\u003e exactly that reason.\n\u003e\n\u003e I don't have the link handy but there's even an example of an experienced\n\u003e cryptographer on this very list (bitcoin-dev) proposing a design that falls\n\u003e victim to this attack. It's a subtle issue and we probably don't want to\n\u003e encourage it.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/bda6e24c/attachment-0001.html\u003e"}