-
-
Notifications
You must be signed in to change notification settings - Fork 125
Frequently Asked Questions
Reticulum: A cryptographically centered network stack. Also generally refers to the entire project and associated systems.
RNS: The Reticulum Network Stack: the routed network stack underlying all of Reticulum.
Shared Instance: The RNS only starts once per machine, and all other programs connect to it. However, if the first one goes down, they all lose their connection. This is why the RNS daemon (rnsd) is run as a service or prior to any other application.
Sideband: A cross platform, Kivy powered, GUI messenger app. It includes image, voice, and telemetry features, including distributed telemetry and situation mapping.
Nomad Network: A terminal-based messenger app that also includes distribution net, page, and page viewing capabilities.
MeshChat: A cross platform messenger app that includes image, voice, and additional features, such as preliminary page viewing capabilities. Under rapid development.
Distribution Net: An E2EE message store to allow storage of messages for offline destinations.
LXMF: Lightweight Extensible Message Format. A message format built for Reticulum that supports text or binary encoded information. Typically uses "fields," which are msgpack'd byte arrays that allow images, audio, files, telemetry, etc. to be attached to message and handed by the end user while maintaining full backwards compatibility (a new field or message type will remain unhandled, but feed bad data into the app)
LXMRouter: The system that actually routes LXMF messages, and is run behind the scenes for Sideband, NomadNet, and MeshChat.
Reticulum works by having local routing tables. When a destination announces its presence, it sends its address and public key on all known interfaces. Each interface that sees it processes it, and depending on its hop count and the interface mode, may pass it along.
When a router processes an announce, it determines if the path is better than any other known path, then stores it, along with the next hop. This means when a router is handed a packet with an address, they know the next step in the routing table, and only the next step. There is no global routing table and paths are dynamically generated as topography changes.
The details of how announces are propagated and complicated and can break down the network topography into chunks of a sane size, but the most important concept is the gateway. While any peer can query the network to ask if a path and public key are known, a gateway proactively attempts to find any identities it doesn't know. Because of this, network segments can store only the local announces and query the network for other identities.
For those familiar with DNS, this is not unlike a local name server that knows the local hosts, but must query another server when an unknown server is requested. The major difference is in this case it doesn't need an upstream server, it can query the network as a whole.
It's hard to say without knowing both systems rather well. Reticulum is a routed network stack that functions over multiple media, physical and virtual, including TCP, RF, Serial, and I2P.
If you're asking about a messenger app, then you're comparing it to Sideband or Nomad Network, which uses LXMF to transmit messages over Reticulum.
If you're asking about a LoRa radio messenger, then it provides multiple physical interfaces beyond LoRa.
If you're asking about a file transfer app, then LXMF can transfer files across Reticulum with E2EE.
If you're asking about voice transmissions, then LXMF uses CODEC2 to transmit voice at approximately 2400 bps while still being intelligible. Due to the limitations of CODEC2, this will not be the quality of typical VoIP, but a custom Reticulum app could provide VoIP-like communications over high-speed links.
If you're a developer, it's a network stack. It transfers data. It is end to end encrypted and uses ephemeral AES encryption over links established using public/private key exchanges. It currently lacks multicast (for encryption reasons) but the "group" destination with distributed routing is currently under development.
Reticulum prizes efficiency, decentralization, and security. Without examining other projects from the ground up, this is as good a primer as possible.
Short version: Used properly, Reticulum meets or exceeds industry standards. It has forward secrecy and uses proven cryptographic primitives in proven methods. If any of these standards become insecure, Reticulum is designed for easy replacement of cryptographic standards.
Used improperly, it remains encrypted using a slower, less secure standard with no forward secrecy. As most networking stacks use optional encryption, this makes Reticulum more secure by default.
Long version: Most sustained communication in Reticulum is performed over a link. These links are AES encrypted with an ephemeral key based on a DH key exchange. This provides fast, secure, forward secret encryption. Virtually every communication is signed, providing an assurance that the encrypted data and even exposed metadata is authentic.
With the exception of unrouted packets, mostly announces generated to distribute public keys and pathing information, all packets in Reticulum are encrypted. The only exposed information is a two byte header, a one byte context field, and the destination address. The header contains single flag, the header, propagation, destination, and packet types, and the number of hops. No other information is exposed. Basic packets don't include the source address even in the encrypted data, and no router ever sees more than one hop in either direction, and unless the sender chooses to identify themselves, there is no way to determine the sender from the received packet.
From a risk management perspective, cracking the AES encryption on a single link will only reveal the communications from that link session. Cracking the asymmetric keys will only allow decryption of base packets and any key exchanges that were recorded by the attacker.
By avoiding novel encryption, Reticulum uses proven industry standards to create a secure network stack that avoids the attack vectors inherent in other stacks.
Forward secret means that if the encryption of a single exchange is broken, no other exchange is compromised. This means if not all traffic is sensitive, it's possible an attacker could spend days, months, or even years of machine time to decrypt a lunch order, and all other messages remain secure.
This is not legal advice, as even if a contributor is a lawyer, they are not your lawyer.
So long as encrypted communication is legal in your jurisdiction, it's almost certain Reticulum itself is legal. Reticulum is always encrypted, so any law preventing encryption will affect its legality.
In many jurisdictions, transmitting encrypted data over the radio is restricted, especially in amateur radio bands. Any license will clearly state what can and cannot be done on the band, be it a public or private band.
Unlicensed bands vary greatly between band and jurisdiction. This can cover not just frequency, but duty cycle and radiated power (both in raw dBm and in directed power, taking into account a directional antenna). For example, Digikey provides some basic guidance regarding LoRa products, but even this requires substantial investigation to ensure compliance. Many of the supported RNode boards from LilyGO are both FCC certified and are within frequency and power limits for most regions.
If your jurisdiction has laws regarding "service providers" for E2EE messengers, the distribution network functionality of NomadNet can be disabled, turning a node into a router without any storage of user data (which is encrypted and unavailable to the server in any case). Similarly, a node doesn't need to have a TCP server, further isolating the node from such restrictions.
Reticulum is as legal as any other system providing the same functionality, so laws regarding encryption over the Internet, radio, telephone, wire, broadcast, etc. all apply. This is a tremendously complicated field, and if there's any question, a specialist attorney would need to be told the specific application in question.
As a routed network, a packet sent to a single destination would go through a single path and likely jam a single router. Sending packets to multiple other destinations would cause issues for local routers, but the larger network would be less affected as paths diverge. This is generally true of all routed networks, and proper interface settings and topography can assist in a single router's overload not affecting the wider network.
There is a conceptual threat behind using announces, which are generally a TTL enabled flood route, but there are systems in place to mitigate this.
First, annouces have a bandwidth cap. No matter the number of announces pending, a router will use the bulk of its bandwidth for transmitting messages, not announces. Second, announce flood triggers special logic that prevents unknown destinations from broadcasting large numbers of announces, allowing known-good destinations to continue unimpeded operation and queuing any suspicious announces until they can be rebroadcast at a reasonable rate after the burst has concluded. Third, individual servers can limit announce rates of all destinations, preventing a destination from announcing far more frequently than is useful.
Nothing. This is a matter for local authorities, be it law enforcement or the private owner of the band. Electronic warfare is a major discipline and solutions to this issue are of international interest. That being said, radio direction-finding is a mature technology and RF power drops off quickly, so leading enforcement to a jammer is somewhat trivial; it's like finding what light bulb was left on.
This varies significantly and is becoming far more consistent. Most Pi-like SBCs can run the network stack and a node without issue, although the Gen 1 and Zeroes tend to require manual compilation of the crypto libraries or a less secure pure-Python implementation. Through experimentation, a major node can run on a single core in the GHz class with about 780 MB of RAM. This includes file transfer and other capability, but this is application specific, as Reticulum can load a file and transfer it, requiring the file be loaded into RAM, or stream it directly with a much lower overhead. At time of writing, major nodes are running on a 2 gig VM, a Pi 4, and a 2 gig Le Potato.
A pure router written in C for microcontrollers is under development, but does not currently support all features of the network stack.
Line of sight.
The distance varies so wildly, that's the best answer available. Tests from a node in a house to inside a car across hilly, wooded terrain had links available to around one kilometer. Some tests in major cities had a range of a hundred meters. SSH sessions have been successfully used over 16 kilometers. Much greater distances have been reported with more or less evidence available.
The location of the antenna will make a substantial difference, as will the intervening terrain. Models are only available for determining the effects of changes on a known system, not to estimate range whole cloth.
Depends on the hardware. ESP32 based devices idle at around 150 mA for planning numbers, and varies wildly with transmit power.
nRF52 based systems have dramatically lower idle power consumption.
Many of the boards RNode supports technically support up to 20 dBm, but are only rated to 17 for continuous operation. The Semtech datasheets are clear they can only be run at 20 dBm at a small duty cycle, but can be frustratingly vague on the specifics. As an announce may take up to 30 seconds at slower data rates (where you'd be more likely to use high power) and the IoT model for LoRa tends to expect very short transmission times, it's nearly certain an RNode at 20 dBm would damage itself nearly immediately. The firmware for the boards that only support 17 dBm continuous will cap the power, and if the software tries to push it further, the RNode will report the radio is at 17, and the software will see that as a Radio State Mismatch error.
To understand the issue, it's important to note that 20 dBm is twice the power of 17 dBm. If, for example, the RNode draws an additional 100 mA when transmitting at 17, then it will, assuming linear efficiency (which is almost certainly incorrect) it will draw an extra 200 mA at 20. This is ~600 mW of heating as the theoretical radiated energy is 100 mW at perfect efficiency. However, the VSWR of many of the stock antennas reflect around half the transmit power, feeding that 50 mW directly back into the transmitter.
As wider advice, that 3 dB gain may gain up to 50% more range, but as a practical matter with RNodes a well-tuned antenna can reduce the loss in the antenna and add directional gain, allowing a carefully crafted RNode at 17 dBm to actually outperform one at 20 dBm while consuming basically half the current.
If increased power is required beyond antenna gain, there are other units that support 20 - 30 dBm continuous, and actively cooling the RNode may or may not make a difference, but if the RNode in your hands is limiting you to 17 dBm, it should be respected unless you're willing to destroy a few in testing.
Note: As with all wikis, this information is only as accurate as the author. More accurate but still user friendly corrections are always welcome. - Mike