rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2019-10-04 📝 Original message: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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/9c383745/attachment.sig>