infogulch
/
notebook
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Add security section

This commit is contained in:
infogulch 2021-07-09 01:00:39 +00:00
parent 53a6f8d5cd
commit adc0dcb270
1 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
2021-07-07-Merklist.ipynb
View File

@ -6,7 +6,7 @@
"metadata": {},
"source": [
"# Merklist\n",
"> A definition for the hash of a list that is robust to arbitrary partitioning\n",
"> An associative definition for the hash of an ordered sequence of elements\n",
"\n",
"- toc: true\n",
"- categories: [merklist]"
@ -636,12 +636,22 @@
},
{
"cell_type": "markdown",
"id": "6cc30cb3-8079-4f8a-9b7c-a3b4f7e384a3",
"id": "624d5cb8-01cb-4c6d-b80a-4b2079e4ad54",
"metadata": {},
"source": [
"# Unknowns\n",
"## Security\n",
"\n",
"This appears to me to be a reasonable way to define the hash of a list. The mathematical definition of a list aligns very nicely with the properties offered by matrix multiplication. But is it appropriate to use for the same things that a Merkle Tree would be? The big questions are related to the valuable properties of hash functions:\n",
"The security of the design of merklist leans on existing cryptographic hash function by the requiring that values that go into the final list digest came from some real hashed preimage, and any implementation can require that the primage of every element must be provided. This means that it's not possible to choose an *arbitrary* element hash as an input to the reduction operation, limiting the blast radius that any specific element can have on the final list digest to the bit fixing that is possible by asic bitcoin miners today. So then the question is if bit fixing is enough to degrade the preimage resistance of the merklist design, and if that is impossible to overcome. (Challenges anyone?)"
]
},
{
"cell_type": "markdown",
"id": "9515603f-f8b5-482a-ae1b-ed504358b860",
"metadata": {},
"source": [
"## Unknowns\n",
"\n",
"This appears to me to be a reasonable way to define the hash of a list. The mathematical description of a list aligns very nicely with the properties offered by matrix multiplication. But is it appropriate to use for the same things that a Merkle Tree would be? The big questions are related to the valuable properties of hash functions:\n",
"\n",
"* Given a merklist summary but not the elements, is it possible to produce a different list of elements that hash to the same summary? (~preimage resistance)\n",
"* Given a merklist summary or sublist summaries of it, can you derive the hashes of elements or their order?\n",
@ -651,7 +661,7 @@
"* Is there a better choice of reduction function that still retains associativity+non-commutativity than simple matmul?\n",
"* Is there a more appropriate size than an 8x8 matrix / 64 bytes to represent merklist summaries?\n",
"\n",
"Matrixes are well-studied objects, perhaps such information is already known. If *you* know something about deriving the preimage of the multiplication of a [matrix ring](https://en.wikipedia.org/wiki/Matrix_ring), $R_{256}^{8×8}$, I would be very interested to know."
"Matrixes are well-studied objects, perhaps some of these questions already have an answer. If *you* know something about deriving a preimage of a [matrix ring](https://en.wikipedia.org/wiki/Matrix_ring) $R_{256}^{8×8}$ using just multiplication, I would be very interested to know. Given the simplicity of the definition, I wouldn't be surprised if there was already a big wrench in the cogs here."
]
},
{
@ -659,9 +669,9 @@
"id": "4c4d4a83-8e2e-46d7-b2e3-2d59ba9c9e8c",
"metadata": {},
"source": [
"# What's next?\n",
"## What's next?\n",
"\n",
"***If** this construction has the appropriate security properties*, it seems to be a better merkle tree in all respects. Any use of a merkle tree could be replaced with this, and it could enable use-cases where merkle trees aren't useful. Some examples of what I think might be possible:\n",
"*If this construction has appropriate security properties*, it seems to be a better merkle tree in all respects. Any use of a merkle tree could be replaced with this, and it could enable use-cases where merkle trees aren't useful. Some examples of what I think might be possible:\n",
"\n",
"* Using a Merklist with a sublist summary tree structure enables creating a $O(1)$-sized 'Merklist Proof' that can verify the addition and subtraction of any number of elements at any single point in the list using only $O(log(N))$ time and $O(log(N))$ static space. As a bonus the proof generator and verifier can have totally different tree structures and can still communicate the proof successfully.\n",
"* Using a Merklist summary tree you can create a consistent hash of any ordered key-value store (like a btree) that can be maintained incrementally inline with regular node updates, e.g. as part of a [LSM-tree](https://en.wikipedia.org/wiki/Log-structured_merge-tree). This could facilitate verification and sync between database replicas.\n",