Project website is here: https://reticulum.network From the PDF manual: >Reticulum is a cryptography-based networking stack for building both local and wide-area networks with readily available hardware, that can continue to operate under adverse conditions, such as extremely low bandwidth and very high latency. >Reticulum allows you to build wide-area networks with off-the-shelf tools, and offers end-to-end encryption, forward secrecy, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable packet acknowledgements and more. >Reticulum enables the construction of both small and potentially planetary-scale networks, without any need for hierarchical or bureaucratic structures to control or manage them, while ensuring individuals and communities full sovereignty over their own network segments. >Reticulum is a complete networking stack, and does not need IP or higher layers, although it is easy to utilise IP (with TCP or UDP) as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks. Reticulum is built directly on cryptographic principles, allowing resilience and stable functionality in open and trustless networks. >No kernel modules or drivers are required. Reticulum can run completely in userland, and will run on practically any system that runs Python 3. Reticulum runs well even on small single-board computers like the Pi Zero. More technical details: >The network unit is a "destination" >Destinations are represented as 16 byte hashes of their properties >4 types of destinations: >>Single for single messages to server/host/client programs >>Plain for links/mesh neighbors >>Group for broadcast messages >>Link for persistent connections The algorithmic details appear to involve periodic re-transmission of routing information. Each node in the mesh network keeps a table with one record per single destination containing the neighbor closest to each single destination. My reading of the document's explanation of the announce mechanism, each routing user is likely to record at least one single destination for each program using the network. The network is likely to be reliable in practice, assuming sufficient book-keeping resources. Each routing node in the mesh network also keeps track of every active link going across it, so there is also one record for each such link. This is a significant increase in book-keeping relative to TCP, but also represents a significant improvement in server-client privacy relative to TCP. Group message routing is supposedly a planned upgrade, although I am not sure of the possibility for simultaneously achieving efficient book-keeping, non-redundant message transmission and reliability in the group message context. Document Pros: >The algorithms appear to be documented in detail, including announcements, routing and link establishment. >The wire format appears to be documented in detail. >The summary details a number of intended security features, all of which appear to be true except those which may be over-claiming efficiency. Document Cons: >Algorithms are documented, but the intended and actual properties of these algorithms are not. >>Time and memory complexity for routing (believed O(log(N)) and O(N) for N destinations) >>Time and memory complexity for book-keeping (believed O(log(N)) and O(N) for N destinations) >>Optimality/non-optimality of the network >Deletion of single destinations appears to be undocumented. >The document is a PDF, but does not take advantage of the PDF format to include figures and diagrams that would assist in explanation of its algorithms. >Claims security, but no explication of security models. >There do not appear to be any algorithms for detecting and eliminating bad actors in the network. >Section 1.5 "Caveat Emptor" claims to want an audit, but no statement of relevant desirable cryptographic/security properties that are claimed as desirable or undesirable. From a security perspective, the wording of this disclaimer is a red flag in itself, suggesting the author is unaware of potential security models and failure modes in mesh networking literature. This suggests a need for additional help even before asking for an audit. >The previous two issues would be lessened if a bibliography were provided instead, and references to that bibliography in place throughout relevant portions of the document. This decouples the author's task, as they can refer to pre-existing literature to describe important properties and focus audit work on the implementation itself. It is likely the actual implementation of the cryptography is sufficient for its purpose. >A dilemma seems to be inherent in explaining the advantages of the protocol: the degree of advertising reliability as opposed to security. The link establishment protocol requires buying into the mesh networking, and is good for security. However, the mesh networking itself has other security properties that make it poor, discussed later, relating to leaf nodes and bottlenecks. Protocol Pros: >Routable links allow for initiating persistent connections without knowing the source and is an improvement over TCP, which requires a return address. The cost is that using this mechanism requires buying into a pre-routed link provided by the network. Even with this cost, this remains an improvement over TCP. However, it seems unlikely that links themselves can be repaired as the network itself can. This is not what I would consider a true session construction mechanism, but potentially useful in spite of this. This is a nice trick, and I might steal it.

[Expand Post]

>To my understanding, reliability is practically guaranteed in a cooperative network with sufficient computational resources for book-keeping. >Designed specifically for handling heterogeneous networking. Protocol Cons: >Necessary book-keeping appears to strongly favor an infrastructure of "uber-routers" and leaves as the network grows, i.e. routing nodes owned by ISPs. >The network does not appear to have any protection against hostile actors and appears to favor "hyper-router" hostile actors performing denial-of-service attacks, possibly including ISPs. >Leaf nodes identify themselves to their routers (i.e. ISPs), which may be conspiring to take advantage of network metadata. Similarly, bottleneck nodes get information about where links are going. Review: The protocol has some appealing properties combined with some problems likely to be show-stoppers for particular applications. It would benefit the most from clear statements of explicit security models, what is considered out-of-scope for security, and the inclusion of algorithmic properties, especially algorithmic complexity of book-keeping. Practical use for high-security systems would likely require it to be used in a complementary fashion, for example as an underlying transport for a privacy-enhancing system. It appears to have a major scalability issue of O(N) book-keeping that could prevent its practicality in larger networks.