📅 Original date posted:2014-02-05
📝 Original message:On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd <pete at petertodd.org> wrote:
>
> On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
> > Because it's trivial to create collisions! You can choose exactly what
> > output you want. That's why XOR is a very bad digest scheme.
>
> You're close, but not quite.
>
> So, imagine you have a merkle tree, and you're trying to timestamp some
> data at the bottom of the tree. Now you can successfully timestamp the
> top digest in the Bitcoin blockchain right, and be sure that digest
> existed before some time. But what about the digests at the bottom of
> the tree? What can an attacker do exactly to make a fake timestamp if
> the tree is using XOR rather than a proper hash function?
>
Given a tree like:
G
/ \
E F
/ \
C D
/ \
A B
Where G is the root hash and A is the legitimate data that was included in
the tree, the legitimate user provides B, D and F along with A to prove A
is part of the tree G.
Now an attacker could just make up an arbitrary set of values that XOR
together into G, like:
G
/ \
Z Y
And could therefore claim Z is part of tree G by providing Y. But if A is
also trying to prove its a part of G, we know the first level of the tree
must be E and F. It cannot also be Z and Y, so one of the two users is
lying and the deceit is obvious, though not obvious which user is lying.
An attacker could look more convincing by using the data passed with A as a
starting point:
G
/ \
E F
/ \
/ \
/ \
C D
/ \ / \
A B Z Y
Instead of working off of G, work of the lowest branch provided by A in its
verification (D, in this case), and create the fake data Z, and calculate Y
such that Z XOR Y == D (which is just Z XOR D). Now the attacker can claim
Z is part of G by supplying Y, C, and F. The tree looks valid (it can
coexist with the proof provided by A, at least until someone else claims to
be a descendant of the D node as well), and since G was verified by
timestamp, looks like Z existed before that timestamp, when really it could
be added at any time by calculating Z XOR D.
Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140205/25eaf6b2/attachment.html>;
Brooks Boyd [ARCHIVE] /
npub12h…vtmxa
2023-06-07 15:13:01
in reply to nevent1q…662r
Author Public Key
npub12hzwfhx9ptjf2f0va8qllc0h4tcvz5aaefvlvn9uq8z2ssrq027qtvtmxaPublished at
2023-06-07 15:13:01Event JSON
{
"id": "2fdbc0261b25373318597e49a6e7c5dc4c3816140cd7849a15ddb6bca72e372d",
"pubkey": "55c4e4dcc50ae49525ece9c1ffe1f7aaf0c153bdca59f64cbc01c4a840607abc",
"created_at": 1686150781,
"kind": 1,
"tags": [
[
"e",
"0461b7f04f9c2fd1728908910e1d69985b9bedd999a7fe9c6d8f15fcbbae84d8",
"",
"root"
],
[
"e",
"9396230f2a4d7ab03dac52ada664083289a977047ff4f9ff34ef2056008d19af",
"",
"reply"
],
[
"p",
"7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3"
]
],
"content": "📅 Original date posted:2014-02-05\n📝 Original message:On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\n\u003e On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:\n\u003e \u003e Because it's trivial to create collisions! You can choose exactly what\n\u003e \u003e output you want. That's why XOR is a very bad digest scheme.\n\u003e\n\u003e You're close, but not quite.\n\u003e\n\u003e So, imagine you have a merkle tree, and you're trying to timestamp some\n\u003e data at the bottom of the tree. Now you can successfully timestamp the\n\u003e top digest in the Bitcoin blockchain right, and be sure that digest\n\u003e existed before some time. But what about the digests at the bottom of\n\u003e the tree? What can an attacker do exactly to make a fake timestamp if\n\u003e the tree is using XOR rather than a proper hash function?\n\u003e\n\nGiven a tree like:\n\n G\n / \\\n E F\n / \\\n C D\n / \\\nA B\n\nWhere G is the root hash and A is the legitimate data that was included in\nthe tree, the legitimate user provides B, D and F along with A to prove A\nis part of the tree G.\n\nNow an attacker could just make up an arbitrary set of values that XOR\ntogether into G, like:\n\n G\n / \\\nZ Y\n\nAnd could therefore claim Z is part of tree G by providing Y. But if A is\nalso trying to prove its a part of G, we know the first level of the tree\nmust be E and F. It cannot also be Z and Y, so one of the two users is\nlying and the deceit is obvious, though not obvious which user is lying.\n\nAn attacker could look more convincing by using the data passed with A as a\nstarting point:\n\n G\n / \\\n E F\n / \\\n / \\\n / \\\n C D\n / \\ / \\\nA B Z Y\n\nInstead of working off of G, work of the lowest branch provided by A in its\nverification (D, in this case), and create the fake data Z, and calculate Y\nsuch that Z XOR Y == D (which is just Z XOR D). Now the attacker can claim\nZ is part of G by supplying Y, C, and F. The tree looks valid (it can\ncoexist with the proof provided by A, at least until someone else claims to\nbe a descendant of the D node as well), and since G was verified by\ntimestamp, looks like Z existed before that timestamp, when really it could\nbe added at any time by calculating Z XOR D.\n\nBrooks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140205/25eaf6b2/attachment.html\u003e",
"sig": "8341b4020d0945b6ee48cc30847c8e93368238aea3d4f19a12da8ccb64e14bd1e430492297ed2fc21327739310f3ad9abed0d0f2c581701809b45ff1c0442f84"
}