rich1.0npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtahttps://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtanjumphttps://nostr.ae📅 Original date posted:2019-10-04 📝 Original message:Interesting point. The script is under your control, so you should be able to ensure that you are always using a correctly constructed midstate, e.g., something like: scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2> OP_SHA256STREAM <hash> OP_EQUALVERIFY would hash all the elements on the stack and compare to a known hash. How is that sort of thing weak to midstateattacks? -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Oct 4, 2019 at 4:16 AM Peter Todd <pete at petertodd.org> wrote: > 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. > > > > You can then use it perhaps as follows: > > > > // 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] > > > > <-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 > directly; > preventing that would require adding types to the stack. Specifically I > could > 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 > anyone > 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. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/bda6e24c/attachment-0001.html>