<div dir="ltr"><div class="gmail_default" style="font-size:small">I am now working on the Mathematical Mesh full time and independently. At present, I am working through the Mesh specifications and code piece by piece getting the specifications in line with the code as implemented.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My new company 'Venture Cryptography LLC' is in process of formation (read Phill better get his application in to the IRS for a tax code so he can register it). The business model I am currently looking at is basically a branding play. In the first phase someone has a startup and they want to persuade people they have some clue about security we can look at their stuff and see if it makes sense on a fee plus equity basis. Once we get to some idea of quantifiable security assurances for IoT etc. devices we can start an approval mark program.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Naming (UDF) and Message Format (DARE Message/Container) parts are more or less complete and I am now working to get the profile and messaging documentation properly in sync.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One major change in the specifications is that I realized that I could generalize all the various Mesh applications (Contacts, Calendar, Bookmarks, etc) into two general structures, Catalogs and Spools. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A Catalog is simply a collection of objects which is managed by a single party. So the set of my usernames and passwords is the credentials catalog. The set of tasks is my calendar and so on.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A spool is a queue of messages. Messages are the only structure that are exchanged between users. So if I want to ask Alice to add me to her contacts, I send her a contact request message which is access controlled for spam prevention and added to her inbound message spool. If she accepts the request, she marks it as read by appending a message read entry to the spool and then adds the contact to her contacts catalog.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Spools and catalogs are both implemented as DARE containers which are append only logs. So the only protocol primitive needed is the ability to synchronize a container from a master to a set of (possibly redacted) copies. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As I was working on this structure, I realized that it would be awfully convenient to bound the size of messages so that the spools remained compact. Bounding the message size to 63K allows messages to fit into one IP packet with some headroom for tunneling (yes, I know that the current MTU limit is 1500 bytes or 9000 ish ).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This decision came from the decision to support very large payloads. Once you decide to support email transfers of 4K video files between users, it is obvious that you need to separate control and data paths. So large messages are going to have to be sent as attachments separate from the body or as I call them, detachments. This approach has other advantages, it means I can send a living document that is being constantly updated with the same ease as a static finished one.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So my messages are all looking like they will be less than 64K. (Possibly less than 9K). Perhaps I should make all the messages the same size so as to provide protection against traffic analysis.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't plan to implement this feature at this stage and will probably leave that to others to do. But what is the current state of the art in mixmaster type networks for asynchronous messaging?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In particular, where is the optimum tradeoff between security and complexity?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When I read crypto papers, they seem to assume that the ideal is to achieve anonymous communications with the intermediary nodes being unable to trace the path of the packets. I really doubt that capability has more than theoretical application. Being able to protect a military network against a Pentagon Pizza Parlor attack is probably much more useful. It is certainly simpler.</div></div>