š
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/lightning-dev/attachments/20191004/9c383745/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-09 12:56:31
in reply to nevent1qā¦7jll
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-09 12:56:31Event JSON
{
"id": "a582435e68c782f242edadb2b1c515cf77064343aa09cb70ad40bc7e3b4df096",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686315391,
"kind": 1,
"tags": [
[
"e",
"c5d8507cb01403cca52393e447a3bb6ef2b92cd8808850618c924b0bc2f035fb",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2019-10-04\nš Original message:\nOn 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/lightning-dev/attachments/20191004/9c383745/attachment.sig\u003e",
"sig": "1d7d0dec707f29297104adc711c76411f13ffbdf1ba249e11a562838f2b65e8e75e96d25c217bbc8f24faa9df7caf72b69df8e05dc3927180bac07b28255c275"
}