<div dir="ltr"><div class="gmail_default" style="font-size:small">Looking for review and comment on the following:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html">http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html</a>  <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The context for which this is designed for is described here but that document is not complete, it is waiting on the code being finished.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html">http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html</a>  <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I presented a part of the Mesh to a closed audience yesterday. Their response was 'this is blockchain for encryption'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now as many of you know, I avoid the term 'blockchain' because, well there is a huge amount of fraud in the crypto-currency world and one of the biggest frauds is the security claims being made. And there is a huge price bubble that is inevitably going to burst some time. And there is that business of using 0.5% of global energy to support the system.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The audience in question specializes in information engagement and they told me that what I was describing was blockchain encryption and either I described it as such or people won't understand it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The DARE container format is an append only log file with integrity checks via a Merkle Tree and incremental encryption. Any record in the chain can be encrypted under the (salted) result of a key exchange presented earlier in the chain.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So one application could be incremental encryption of server log files. Attempting to encrypt a log file by performing an RSA encryption of each entry is obviously nonsense from the performance and data volume point of view. Curve25519 is a little more practical but is still more overhead than is likely to be tolerable.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The DARE structure uses a public key exchange to establish a master key. Individual records can then be encrypted under a key generated from that master key by means of HKDF Key Generation with a unique per entry salt.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The net result is that the DARE format can be used to encrypt arbitrary numbers of entry or arbitrary size bounded only by the limitations of the encryption algorithm (2^39 for AES), data length (2^63) and nonce size (2^125 for the UDF scheme). These limitations could be lifted if people think there is a good argument to do so. The only one I think might be an issue is the one imposed by AES.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As you would expect from me, the format supports use of split decryption keys so that decryption of the data can be gated on a decryption key share in the cloud that does not have decryption capability by itself.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The container format supports rapid traversal in either direction by the inclusion of frame length indicators at the start AND end of each frame (always), Merkle tree indexing (optional) and direct indexing (defined but not yet implemented).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Merkle tree can be signed to provide non repudiable authentication for the entire tree.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Besides GDPR compliant server logs, I can think of many, many applications. I use the structure extensively in the Mesh to manage sets and lists of entries. One of the applications I have always had in mind is end-to-end secure Web services including chat rooms and comment forums/mailing lists.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So is there anything I must add?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Right now, I have not published my MetaNotary protocol because I haven't implemented it. I have published the basis for the analysis though in the trust paper.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A MetaNotary is simply any notary that includes the outputs of other notaries. Thus it is possible to prove quite easily that no other scheme can ever present a higher work factor than a MetaNotary since if such a notary existed, the MetaNotary can simply consume its output as an input and present at least equal the work factor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The incentives for participating in a MetaNotary are very interesting and very similar to the arguments I made when I invented the referer field in HTTP as a mechanism to support advertising.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Let us say that there are notaries A and B who both serve separate communities. The communities rate their notaries according to the work factor that they present. Let us also suppose that notary C would like to enter the market.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Notary C can offer a higher work factor than A or B by consuming both as inputs. A and B can however match the outputs of C by agreeing to consume each other as input.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Simulations show that the optimal strategy for notaries would be to consume as many other notaries outputs as possible so as to increase their work factor as much as possible and also to provide an incentive to other notaries to consume their outputs as input.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The net is that I expect to see a notary structure emerge that is similar in structure to the PGP keyserver infrastructure that has emerged based on Brian LaMacchia's original MIT key server. Essentially, any notary will be able to gain notarization of their output and fixing of their input by contributing to and consuming from one or more public metanotaries.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In short, the system will hold together through reciprocity. Since <a href="http://metanotary.com">metanotary.com</a> was taken, I call this the emergent reciprocal meta-system the internotary.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">While there are still arguable advantages of the Satoshi consensus mechanism in terms of performance, it is an algorithm that cannot be made efficient because it is the inefficiency of the algorithm that makes the Satoshi consensus work. The internotary offers a different but compelling compromise between partitioning, availability and consistency at negligible cost. Furthermore, the internotary consensus does not require any consumption of resources of any type.</div><div class="gmail_default" style="font-size:small"><br></div></div>