📅 Original date posted:2014-02-05
📝 Original message:Well the point of the Merkle tree is that if I all you have is the top,
and all I give you is a leaf node and the siblings of all parents of that
leaf, then by simply hashing you can check if the node was actually
present in the tree.
The only reason this works is because it's hard for an attacker to come up
with the list of values which would ultimately hash together to produce
the expected top value. But if the hash function is actually just XOR, it
becomes completely trivial for me to claim any value I want was in the
tree.
1) Pick the fake value you want to claim was in the tree (leaf node)
2) Choose some random values to fake the depth in the tree
3) Calculate the last value as 'Prev (x) Top'
4) When your victim goes to verify set membership, they will get the top
value they expected
On Tue, 04 Feb 2014 08:04:14 -0800, 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?
Jeremy Spilman [ARCHIVE] /
npub10e…jc727
2023-06-07 15:13:01
in reply to nevent1q…nsqg
Author Public Key
npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727Published at
2023-06-07 15:13:01Event JSON
{
"id": "9396230f2a4d7ab03dac52ada664083289a977047ff4f9ff34ef2056008d19af",
"pubkey": "7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3",
"created_at": 1686150781,
"kind": 1,
"tags": [
[
"e",
"0461b7f04f9c2fd1728908910e1d69985b9bedd999a7fe9c6d8f15fcbbae84d8",
"",
"root"
],
[
"e",
"b5c483f857554396ccb993f322abdb12adf41ab808bc91406cd65ee529496064",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-02-05\n📝 Original message:Well the point of the Merkle tree is that if I all you have is the top, \nand all I give you is a leaf node and the siblings of all parents of that \nleaf, then by simply hashing you can check if the node was actually \npresent in the tree.\n\nThe only reason this works is because it's hard for an attacker to come up \nwith the list of values which would ultimately hash together to produce \nthe expected top value. But if the hash function is actually just XOR, it \nbecomes completely trivial for me to claim any value I want was in the \ntree.\n\n1) Pick the fake value you want to claim was in the tree (leaf node)\n2) Choose some random values to fake the depth in the tree\n3) Calculate the last value as 'Prev (x) Top'\n4) When your victim goes to verify set membership, they will get the top \nvalue they expected\n\n\n\nOn Tue, 04 Feb 2014 08:04:14 -0800, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\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?",
"sig": "425dc5b8f731ebc7456fd2a14eaefbeb8984a3e37c48c1943668d246330e66fa850e93eb7351a40dafb03396313964d95d980559d643b2a41f156170a1184143"
}