[Cryptography] Mix Messaging in the Mesh

[Phillip Hallam-Baker]

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.

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.

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.

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.

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.

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.

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.

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 ).

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.

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.

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?

In particular, where is the optimum tradeoff between security and
complexity?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190321/fad93572/attachment.html>