understanding.html
1 <!doctype html> 2 <html class="no-js" lang="en" data-content_root="./"> 3 <head><meta charset="utf-8"> 4 <meta name="viewport" content="width=device-width,initial-scale=1"> 5 <meta name="color-scheme" content="light dark"><meta name="viewport" content="width=device-width, initial-scale=1" /> 6 <link rel="index" title="Index" href="genindex.html"><link rel="search" title="Search" href="search.html"><link rel="next" title="Communications Hardware" href="hardware.html"><link rel="prev" title="Using Reticulum on Your System" href="using.html"> 7 <link rel="prefetch" href="_static/rns_logo_512.png" as="image"> 8 9 <!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 --> 10 <title>Understanding Reticulum - Reticulum Network Stack 1.1.3 documentation</title> 11 <link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" /> 12 <link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" /> 13 <link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" /> 14 <link rel="stylesheet" type="text/css" href="_static/styles/furo-extensions.css?v=8dab3a3b" /> 15 <link rel="stylesheet" type="text/css" href="_static/custom.css?v=bb3cebc5" /> 16 17 18 19 20 <style> 21 body { 22 --color-code-background: #f2f2f2; 23 --color-code-foreground: #1e1e1e; 24 25 } 26 @media not print { 27 body[data-theme="dark"] { 28 --color-code-background: #202020; 29 --color-code-foreground: #d0d0d0; 30 --color-background-primary: #202b38; 31 --color-background-secondary: #161f27; 32 --color-foreground-primary: #dbdbdb; 33 --color-foreground-secondary: #a9b1ba; 34 --color-brand-primary: #41adff; 35 --color-background-hover: #161f27; 36 --color-api-name: #ffbe85; 37 --color-api-pre-name: #efae75; 38 39 } 40 @media (prefers-color-scheme: dark) { 41 body:not([data-theme="light"]) { 42 --color-code-background: #202020; 43 --color-code-foreground: #d0d0d0; 44 --color-background-primary: #202b38; 45 --color-background-secondary: #161f27; 46 --color-foreground-primary: #dbdbdb; 47 --color-foreground-secondary: #a9b1ba; 48 --color-brand-primary: #41adff; 49 --color-background-hover: #161f27; 50 --color-api-name: #ffbe85; 51 --color-api-pre-name: #efae75; 52 53 } 54 } 55 } 56 </style></head> 57 <body> 58 59 <script> 60 document.body.dataset.theme = localStorage.getItem("theme") || "auto"; 61 </script> 62 63 64 <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> 65 <symbol id="svg-toc" viewBox="0 0 24 24"> 66 <title>Contents</title> 67 <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 1024 1024"> 68 <path d="M408 442h480c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8H408c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8zm-8 204c0 4.4 3.6 8 8 8h480c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8H408c-4.4 0-8 3.6-8 8v56zm504-486H120c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8h784c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8zm0 632H120c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8h784c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8zM115.4 518.9L271.7 642c5.8 4.6 14.4.5 14.4-6.9V388.9c0-7.4-8.5-11.5-14.4-6.9L115.4 505.1a8.74 8.74 0 0 0 0 13.8z"/> 69 </svg> 70 </symbol> 71 <symbol id="svg-menu" viewBox="0 0 24 24"> 72 <title>Menu</title> 73 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 74 stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather-menu"> 75 <line x1="3" y1="12" x2="21" y2="12"></line> 76 <line x1="3" y1="6" x2="21" y2="6"></line> 77 <line x1="3" y1="18" x2="21" y2="18"></line> 78 </svg> 79 </symbol> 80 <symbol id="svg-arrow-right" viewBox="0 0 24 24"> 81 <title>Expand</title> 82 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 83 stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather-chevron-right"> 84 <polyline points="9 18 15 12 9 6"></polyline> 85 </svg> 86 </symbol> 87 <symbol id="svg-sun" viewBox="0 0 24 24"> 88 <title>Light mode</title> 89 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 90 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="feather-sun"> 91 <circle cx="12" cy="12" r="5"></circle> 92 <line x1="12" y1="1" x2="12" y2="3"></line> 93 <line x1="12" y1="21" x2="12" y2="23"></line> 94 <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> 95 <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> 96 <line x1="1" y1="12" x2="3" y2="12"></line> 97 <line x1="21" y1="12" x2="23" y2="12"></line> 98 <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> 99 <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> 100 </svg> 101 </symbol> 102 <symbol id="svg-moon" viewBox="0 0 24 24"> 103 <title>Dark mode</title> 104 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 105 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-moon"> 106 <path stroke="none" d="M0 0h24v24H0z" fill="none" /> 107 <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z" /> 108 </svg> 109 </symbol> 110 <symbol id="svg-sun-with-moon" viewBox="0 0 24 24"> 111 <title>Auto light/dark, in light mode</title> 112 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 113 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" 114 class="icon-custom-derived-from-feather-sun-and-tabler-moon"> 115 <path style="opacity: 50%" d="M 5.411 14.504 C 5.471 14.504 5.532 14.504 5.591 14.504 C 3.639 16.319 4.383 19.569 6.931 20.352 C 7.693 20.586 8.512 20.551 9.25 20.252 C 8.023 23.207 4.056 23.725 2.11 21.184 C 0.166 18.642 1.702 14.949 4.874 14.536 C 5.051 14.512 5.231 14.5 5.411 14.5 L 5.411 14.504 Z"/> 116 <line x1="14.5" y1="3.25" x2="14.5" y2="1.25"/> 117 <line x1="14.5" y1="15.85" x2="14.5" y2="17.85"/> 118 <line x1="10.044" y1="5.094" x2="8.63" y2="3.68"/> 119 <line x1="19" y1="14.05" x2="20.414" y2="15.464"/> 120 <line x1="8.2" y1="9.55" x2="6.2" y2="9.55"/> 121 <line x1="20.8" y1="9.55" x2="22.8" y2="9.55"/> 122 <line x1="10.044" y1="14.006" x2="8.63" y2="15.42"/> 123 <line x1="19" y1="5.05" x2="20.414" y2="3.636"/> 124 <circle cx="14.5" cy="9.55" r="3.6"/> 125 </svg> 126 </symbol> 127 <symbol id="svg-moon-with-sun" viewBox="0 0 24 24"> 128 <title>Auto light/dark, in dark mode</title> 129 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 130 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" 131 class="icon-custom-derived-from-feather-sun-and-tabler-moon"> 132 <path d="M 8.282 7.007 C 8.385 7.007 8.494 7.007 8.595 7.007 C 5.18 10.184 6.481 15.869 10.942 17.24 C 12.275 17.648 13.706 17.589 15 17.066 C 12.851 22.236 5.91 23.143 2.505 18.696 C -0.897 14.249 1.791 7.786 7.342 7.063 C 7.652 7.021 7.965 7 8.282 7 L 8.282 7.007 Z"/> 133 <line style="opacity: 50%" x1="18" y1="3.705" x2="18" y2="2.5"/> 134 <line style="opacity: 50%" x1="18" y1="11.295" x2="18" y2="12.5"/> 135 <line style="opacity: 50%" x1="15.316" y1="4.816" x2="14.464" y2="3.964"/> 136 <line style="opacity: 50%" x1="20.711" y1="10.212" x2="21.563" y2="11.063"/> 137 <line style="opacity: 50%" x1="14.205" y1="7.5" x2="13.001" y2="7.5"/> 138 <line style="opacity: 50%" x1="21.795" y1="7.5" x2="23" y2="7.5"/> 139 <line style="opacity: 50%" x1="15.316" y1="10.184" x2="14.464" y2="11.036"/> 140 <line style="opacity: 50%" x1="20.711" y1="4.789" x2="21.563" y2="3.937"/> 141 <circle style="opacity: 50%" cx="18" cy="7.5" r="2.169"/> 142 </svg> 143 </symbol> 144 <symbol id="svg-pencil" viewBox="0 0 24 24"> 145 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 146 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-pencil-code"> 147 <path d="M4 20h4l10.5 -10.5a2.828 2.828 0 1 0 -4 -4l-10.5 10.5v4" /> 148 <path d="M13.5 6.5l4 4" /> 149 <path d="M20 21l2 -2l-2 -2" /> 150 <path d="M17 17l-2 2l2 2" /> 151 </svg> 152 </symbol> 153 <symbol id="svg-eye" viewBox="0 0 24 24"> 154 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" 155 stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-eye-code"> 156 <path stroke="none" d="M0 0h24v24H0z" fill="none" /> 157 <path d="M10 12a2 2 0 1 0 4 0a2 2 0 0 0 -4 0" /> 158 <path 159 d="M11.11 17.958c-3.209 -.307 -5.91 -2.293 -8.11 -5.958c2.4 -4 5.4 -6 9 -6c3.6 0 6.6 2 9 6c-.21 .352 -.427 .688 -.647 1.008" /> 160 <path d="M20 21l2 -2l-2 -2" /> 161 <path d="M17 17l-2 2l2 2" /> 162 </svg> 163 </symbol> 164 </svg> 165 166 <input type="checkbox" class="sidebar-toggle" name="__navigation" id="__navigation" aria-label="Toggle site navigation sidebar"> 167 <input type="checkbox" class="sidebar-toggle" name="__toc" id="__toc" aria-label="Toggle table of contents sidebar"> 168 <label class="overlay sidebar-overlay" for="__navigation"></label> 169 <label class="overlay toc-overlay" for="__toc"></label> 170 171 <a class="skip-to-content muted-link" href="#furo-main-content">Skip to content</a> 172 173 174 175 <div class="page"> 176 <header class="mobile-header"> 177 <div class="header-left"> 178 <label class="nav-overlay-icon" for="__navigation"> 179 <span class="icon"><svg><use href="#svg-menu"></use></svg></span> 180 </label> 181 </div> 182 <div class="header-center"> 183 <a href="index.html"><div class="brand">Reticulum Network Stack 1.1.3 documentation</div></a> 184 </div> 185 <div class="header-right"> 186 <div class="theme-toggle-container theme-toggle-header"> 187 <button class="theme-toggle" aria-label="Toggle Light / Dark / Auto color theme"> 188 <svg class="theme-icon-when-auto-light"><use href="#svg-sun-with-moon"></use></svg> 189 <svg class="theme-icon-when-auto-dark"><use href="#svg-moon-with-sun"></use></svg> 190 <svg class="theme-icon-when-dark"><use href="#svg-moon"></use></svg> 191 <svg class="theme-icon-when-light"><use href="#svg-sun"></use></svg> 192 </button> 193 </div> 194 <label class="toc-overlay-icon toc-header-icon" for="__toc"> 195 <span class="icon"><svg><use href="#svg-toc"></use></svg></span> 196 </label> 197 </div> 198 </header> 199 <aside class="sidebar-drawer"> 200 <div class="sidebar-container"> 201 202 <div class="sidebar-sticky"><a class="sidebar-brand" href="index.html"> 203 <div class="sidebar-logo-container"> 204 <img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/> 205 </div> 206 207 <span class="sidebar-brand-text">Reticulum Network Stack 1.1.3 documentation</span> 208 209 </a><form class="sidebar-search-container" method="get" action="search.html" role="search"> 210 <input class="sidebar-search" placeholder="Search" name="q" aria-label="Search"> 211 <input type="hidden" name="check_keywords" value="yes"> 212 <input type="hidden" name="area" value="default"> 213 </form> 214 <div id="searchbox"></div><div class="sidebar-scroll"><div class="sidebar-tree"> 215 <ul class="current"> 216 <li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li> 217 <li class="toctree-l1"><a class="reference internal" href="gettingstartedfast.html">Getting Started Fast</a></li> 218 <li class="toctree-l1"><a class="reference internal" href="zen.html">Zen of Reticulum</a></li> 219 <li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a></li> 220 <li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li> 221 <li class="toctree-l1 current current-page"><a class="current reference internal" href="#">Understanding Reticulum</a></li> 222 <li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li> 223 <li class="toctree-l1"><a class="reference internal" href="interfaces.html">Configuring Interfaces</a></li> 224 <li class="toctree-l1"><a class="reference internal" href="networks.html">Building Networks</a></li> 225 <li class="toctree-l1"><a class="reference internal" href="support.html">Support Reticulum</a></li> 226 <li class="toctree-l1"><a class="reference internal" href="examples.html">Code Examples</a></li> 227 <li class="toctree-l1"><a class="reference internal" href="license.html">Reticulum License</a></li> 228 </ul> 229 <ul> 230 <li class="toctree-l1"><a class="reference internal" href="reference.html">API Reference</a></li> 231 </ul> 232 233 </div> 234 </div> 235 236 </div> 237 238 </div> 239 </aside> 240 <div class="main"> 241 <div class="content"> 242 <div class="article-container"> 243 <a href="#" class="back-to-top muted-link"> 244 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> 245 <path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8v12z"></path> 246 </svg> 247 <span>Back to top</span> 248 </a> 249 <div class="content-icon-container"> 250 <div class="theme-toggle-container theme-toggle-content"> 251 <button class="theme-toggle" aria-label="Toggle Light / Dark / Auto color theme"> 252 <svg class="theme-icon-when-auto-light"><use href="#svg-sun-with-moon"></use></svg> 253 <svg class="theme-icon-when-auto-dark"><use href="#svg-moon-with-sun"></use></svg> 254 <svg class="theme-icon-when-dark"><use href="#svg-moon"></use></svg> 255 <svg class="theme-icon-when-light"><use href="#svg-sun"></use></svg> 256 </button> 257 </div> 258 <label class="toc-overlay-icon toc-content-icon" for="__toc"> 259 <span class="icon"><svg><use href="#svg-toc"></use></svg></span> 260 </label> 261 </div> 262 <article role="main" id="furo-main-content"> 263 <section id="understanding-reticulum"> 264 <span id="understanding-main"></span><h1>Understanding Reticulum<a class="headerlink" href="#understanding-reticulum" title="Link to this heading">¶</a></h1> 265 <p>This chapter will briefly describe the overall purpose and operating principles of Reticulum. 266 It should give you an overview of how the stack works, and an understanding of how to 267 develop networked applications using Reticulum.</p> 268 <p>This chapter is not an exhaustive source of information on Reticulum, at least not yet. Currently, 269 the only complete repository, and final authority on how Reticulum actually functions, is the Python 270 reference implementation and API reference. That being said, this chapter is an essential resource in 271 understanding how Reticulum works from a high-level perspective, along with the general principles of 272 Reticulum, and how to apply them when creating your own networks or software.</p> 273 <p>After reading this chapter, you should be well-equipped to understand how a Reticulum network 274 operates, what it can achieve, and how you can use it yourself. This chapter also seeks to provide an overview of the 275 sentiments and the philosophy behind Reticulum, what problems it seeks to solve, and how it 276 approaches those solutions.</p> 277 <section id="motivation"> 278 <span id="understanding-motivation"></span><h2>Motivation<a class="headerlink" href="#motivation" title="Link to this heading">¶</a></h2> 279 <p>The primary motivation for designing and implementing Reticulum has been the current lack of 280 reliable, functional and secure minimal-infrastructure modes of digital communication. It is my 281 belief that it is highly desirable to create a reliable and efficient way to set up long-range digital 282 communication networks that can securely allow exchange of information between people and 283 machines, with no central point of authority, control, censorship or barrier to entry.</p> 284 <p>Almost all of the various networking systems in use today share a common limitation: They 285 require large amounts of coordination and centralised trust and power to function. To join such networks, you need approval 286 of gatekeepers in control. This need for coordination and trust inevitably leads to an environment of 287 central control, where it’s very easy for infrastructure operators or governments to control or alter 288 traffic, and censor or persecute unwanted actors. It also makes it completely impossible to freely deploy 289 and use networks at will, like one would use other common tools that enhance individual agency and freedom.</p> 290 <p>Reticulum aims to require as little coordination and trust as possible. It aims to make secure, 291 anonymous and permissionless networking and information exchange a tool that anyone can just pick up and use.</p> 292 <p>Since Reticulum is completely medium agnostic, it can be used to build networks on whatever is best 293 suited to the situation, or whatever you have available. In some cases, this might be packet radio 294 links over VHF frequencies, in other cases it might be a 2.4 GHz 295 network using off-the-shelf radios, or it might be using common LoRa development boards.</p> 296 <p>At the time of release of this document, the fastest and easiest setup for development and testing is using 297 LoRa radio modules with an open source firmware (see the section <a class="reference internal" href="#understanding-referencesystem"><span class="std std-ref">Reference Setup</span></a>), 298 connected to any kind of computer or mobile device that Reticulum can run on.</p> 299 <p>The ultimate aim of Reticulum is to allow anyone to be their own network operator, and to make it 300 cheap and easy to cover vast areas with a myriad of independent, interconnectable and autonomous networks. 301 Reticulum <strong>is not</strong> <em>one network</em>, it <strong>is a tool</strong> to build <em>thousands of networks</em>. Networks without 302 kill-switches, surveillance, censorship and control. Networks that can freely interoperate, associate and disassociate 303 with each other, and require no central oversight. Networks for human beings. <em>Networks for the people</em>.</p> 304 </section> 305 <section id="goals"> 306 <span id="understanding-goals"></span><h2>Goals<a class="headerlink" href="#goals" title="Link to this heading">¶</a></h2> 307 <p>To be as widely usable and efficient to deploy as possible, the following goals have been used to 308 guide the design of Reticulum:</p> 309 <ul class="simple"> 310 <li><dl class="simple"> 311 <dt><strong>Fully useable as open source software stack</strong></dt><dd><p>Reticulum must be implemented with, and be able to run using only open source software. This is 312 critical to ensuring the availability, security and transparency of the system.</p> 313 </dd> 314 </dl> 315 </li> 316 <li><dl class="simple"> 317 <dt><strong>Hardware layer agnosticism</strong></dt><dd><p>Reticulum must be fully hardware agnostic, and shall be useable over a wide range of 318 physical networking layers, such as data radios, serial lines, modems, handheld transceivers, 319 wired Ethernet, WiFi, or anything else that can carry a digital data stream. Hardware made for 320 dedicated Reticulum use shall be as cheap as possible and use off-the-shelf components, so 321 it can be easily modified and replicated by anyone interested in doing so.</p> 322 </dd> 323 </dl> 324 </li> 325 <li><dl class="simple"> 326 <dt><strong>Very low bandwidth requirements</strong></dt><dd><p>Reticulum should be able to function reliably over links with a transmission capacity as low 327 as <em>5 bits per second</em>.</p> 328 </dd> 329 </dl> 330 </li> 331 <li><dl class="simple"> 332 <dt><strong>Encryption by default</strong></dt><dd><p>Reticulum must use strong encryption by default for all communication.</p> 333 </dd> 334 </dl> 335 </li> 336 <li><dl class="simple"> 337 <dt><strong>Initiator Anonymity</strong></dt><dd><p>It must be possible to communicate over a Reticulum network without revealing any identifying 338 information about oneself.</p> 339 </dd> 340 </dl> 341 </li> 342 <li><dl class="simple"> 343 <dt><strong>Unlicensed use</strong></dt><dd><p>Reticulum shall be functional over physical communication mediums that do not require any 344 form of license to use. Reticulum must be designed in a way, so it is usable over ISM radio 345 frequency bands, and can provide functional long distance links in such conditions, for example 346 by connecting a modem to a PMR or CB radio, or by using LoRa or WiFi modules.</p> 347 </dd> 348 </dl> 349 </li> 350 <li><dl class="simple"> 351 <dt><strong>Supplied software</strong></dt><dd><p>In addition to the core networking stack and API, that allows a developer to build 352 applications with Reticulum, a basic set of Reticulum-based communication tools must be 353 implemented and released along with Reticulum itself. These shall serve both as a 354 functional, basic communication suite, and as an example and learning resource to others wishing 355 to build applications with Reticulum.</p> 356 </dd> 357 </dl> 358 </li> 359 <li><dl class="simple"> 360 <dt><strong>Ease of use</strong></dt><dd><p>The reference implementation of Reticulum is written in Python, to make it easy to use 361 and understand. A programmer with only basic experience should be able to use 362 Reticulum to write networked applications.</p> 363 </dd> 364 </dl> 365 </li> 366 <li><dl class="simple"> 367 <dt><strong>Low cost</strong></dt><dd><p>It shall be as cheap as possible to deploy a communication system based on Reticulum. This 368 should be achieved by using cheap off-the-shelf hardware that potential users might already 369 own. The cost of setting up a functioning node should be less than $100 even if all parts 370 needs to be purchased.</p> 371 </dd> 372 </dl> 373 </li> 374 </ul> 375 </section> 376 <section id="introduction-basic-functionality"> 377 <span id="understanding-basicfunctionality"></span><h2>Introduction & Basic Functionality<a class="headerlink" href="#introduction-basic-functionality" title="Link to this heading">¶</a></h2> 378 <p>Reticulum is a networking stack suited for high-latency, low-bandwidth links. Reticulum is at its 379 core a <em>message oriented</em> system. It is suited for both local point-to-point or point-to-multipoint 380 scenarios where all nodes are within range of each other, as well as scenarios where packets need 381 to be transported over multiple hops in a complex network to reach the recipient.</p> 382 <p>Reticulum does away with the idea of addresses and ports known from IP, TCP and UDP. Instead 383 Reticulum uses the singular concept of <em>destinations</em>. Any application using Reticulum as its 384 networking stack will need to create one or more destinations to receive data, and know the 385 destinations it needs to send data to.</p> 386 <p>All destinations in Reticulum are <em>represented</em> as a 16 byte hash. This hash is derived from truncating a full 387 SHA-256 hash of identifying characteristics of the destination. To users, the destination addresses 388 will be displayed as 16 hexadecimal bytes, like this example: <code class="docutils literal notranslate"><span class="pre"><13425ec15b621c1d928589718000d814></span></code>.</p> 389 <p>The truncation size of 16 bytes (128 bits) for destinations has been chosen as a reasonable trade-off 390 between address space 391 and packet overhead. The address space accommodated by this size can support many billions of 392 simultaneously active devices on the same network, while keeping packet overhead low, which is 393 essential on low-bandwidth networks. In the very unlikely case that this address space nears 394 congestion, a one-line code change can upgrade the Reticulum address space all the way up to 256 395 bits, ensuring the Reticulum address space could potentially support galactic-scale networks. 396 This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should 397 be sufficient, even far into the future.</p> 398 <p>By default Reticulum encrypts all data using elliptic curve cryptography and AES. Any packet sent to a 399 destination is encrypted with a per-packet derived key. Reticulum can also set up an encrypted 400 channel to a destination, called a <em>Link</em>. Both data sent over Links and single packets offer 401 <em>Initiator Anonymity</em>. Links additionally offer <em>Forward Secrecy</em> by default, employing an Elliptic Curve 402 Diffie Hellman key exchange on Curve25519 to derive per-link ephemeral keys. Asymmetric, link-less 403 packet communication can also provide forward secrecy, with automatic key ratcheting, by enabling 404 ratchets on a per-destination basis. The multi-hop transport, coordination, verification and reliability 405 layers are fully autonomous and also based on elliptic curve cryptography.</p> 406 <p>Reticulum also offers symmetric key encryption for group-oriented communications, as well as 407 unencrypted packets (for local broadcast purposes <strong>only</strong>).</p> 408 <p>Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports, 409 and offers the possibility to easily tunnel Reticulum traffic over IP links such as the Internet or 410 private IP networks.</p> 411 <section id="destinations"> 412 <span id="understanding-destinations"></span><h3>Destinations<a class="headerlink" href="#destinations" title="Link to this heading">¶</a></h3> 413 <p>To receive and send data with the Reticulum stack, an application needs to create one or more 414 destinations. Reticulum uses three different basic destination types, and one special:</p> 415 <ul class="simple"> 416 <li><dl class="simple"> 417 <dt><strong>Single</strong></dt><dd><p>The <em>single</em> destination type is the most common type in Reticulum, and should be used for 418 most purposes. It is always identified by a unique public key. Any data sent to this 419 destination will be encrypted using ephemeral keys derived from an ECDH key exchange, and will 420 only be readable by the creator of the destination, who holds the corresponding private key.</p> 421 </dd> 422 </dl> 423 </li> 424 <li><dl class="simple"> 425 <dt><strong>Plain</strong></dt><dd><p>A <em>plain</em> destination type is unencrypted, and suited for traffic that should be broadcast to a 426 number of users, or should be readable by anyone. Traffic to a <em>plain</em> destination is not encrypted. 427 Generally, <em>plain</em> destinations can be used for broadcast information intended to be public. 428 Plain destinations are only reachable directly, and packets addressed to plain destinations are 429 never transported over multiple hops in the network. To be transportable over multiple hops in Reticulum, information 430 <em>must</em> be encrypted, since Reticulum uses the per-packet encryption to verify routing paths and 431 keep them alive.</p> 432 </dd> 433 </dl> 434 </li> 435 <li><dl class="simple"> 436 <dt><strong>Group</strong></dt><dd><p>The <em>group</em> special destination type, that defines a symmetrically encrypted virtual destination. 437 Data sent to this destination will be encrypted with a symmetric key, and will be readable by 438 anyone in possession of the key, but as with the <em>plain</em> destination type, packets to this type 439 of destination are not currently transported over multiple hops, although a planned upgrade 440 to Reticulum will allow globally reachable <em>group</em> destinations.</p> 441 </dd> 442 </dl> 443 </li> 444 <li><dl class="simple"> 445 <dt><strong>Link</strong></dt><dd><p>A <em>link</em> is a special destination type, that serves as an abstract channel to a <em>single</em> 446 destination, directly connected or over multiple hops. The <em>link</em> also offers reliability and 447 more efficient encryption, forward secrecy, initiator anonymity, and as such can be useful even 448 when a node is directly reachable. It also offers a more capable API and allows easily carrying 449 out requests and responses, large data transfers and more.</p> 450 </dd> 451 </dl> 452 </li> 453 </ul> 454 <section id="destination-naming"> 455 <span id="understanding-destinationnaming"></span><h4>Destination Naming<a class="headerlink" href="#destination-naming" title="Link to this heading">¶</a></h4> 456 <p>Destinations are created and named in an easy to understand dotted notation of <em>aspects</em>, and 457 represented on the network as a hash of this value. The hash is a SHA-256 truncated to 128 bits. The 458 top level aspect should always be a unique identifier for the application using the destination. 459 The next levels of aspects can be defined in any way by the creator of the application.</p> 460 <p>Aspects can be as long and as plentiful as required, and a resulting long destination name will not 461 impact efficiency, as names are always represented as truncated SHA-256 hashes on the network.</p> 462 <p>As an example, a destination for a environmental monitoring application could be made up of the 463 application name, a device type and measurement type, like this:</p> 464 <div class="highlight-text notranslate"><div class="highlight"><pre><span></span>app name : environmentlogger 465 aspects : remotesensor, temperature 466 467 full name : environmentlogger.remotesensor.temperature 468 hash : 4faf1b2e0a077e6a9d92fa051f256038 469 </pre></div> 470 </div> 471 <p>For the <em>single</em> destination, Reticulum will automatically append the associated public key as a 472 destination aspect before hashing. This is done to ensure only the correct destination is reached, 473 since anyone can listen to any destination name. Appending the public key ensures that a given 474 packet is only directed at the destination that holds the corresponding private key to decrypt the 475 packet.</p> 476 <p><strong>Take note!</strong> There is a very important concept to understand here:</p> 477 <ul class="simple"> 478 <li><p>Anyone can use the destination name <code class="docutils literal notranslate"><span class="pre">environmentlogger.remotesensor.temperature</span></code></p></li> 479 <li><p>Each destination that does so will still have a unique destination hash, and thus be uniquely 480 addressable, because their public keys will differ.</p></li> 481 </ul> 482 <p>In actual use of <em>single</em> destination naming, it is advisable not to use any uniquely identifying 483 features in aspect naming. Aspect names should be general terms describing what kind of destination 484 is represented. The uniquely identifying aspect is always achieved by appending the public key, 485 which expands the destination into a uniquely identifiable one. Reticulum does this automatically.</p> 486 <p>Any destination on a Reticulum network can be addressed and reached simply by knowing its 487 destination hash (and public key, but if the public key is not known, it can be requested from the 488 network simply by knowing the destination hash). The use of app names and aspects makes it easy to 489 structure Reticulum programs and makes it possible to filter what information and data your program 490 receives.</p> 491 <p>To recap, the different destination types should be used in the following situations:</p> 492 <ul class="simple"> 493 <li><dl class="simple"> 494 <dt><strong>Single</strong></dt><dd><p>When private communication between two endpoints is needed. Supports multiple hops.</p> 495 </dd> 496 </dl> 497 </li> 498 <li><dl class="simple"> 499 <dt><strong>Group</strong></dt><dd><p>When private communication between two or more endpoints is needed. Supports multiple hops 500 indirectly, but must first be established through a <em>single</em> destination.</p> 501 </dd> 502 </dl> 503 </li> 504 <li><dl class="simple"> 505 <dt><strong>Plain</strong></dt><dd><p>When plain-text communication is desirable, for example when broadcasting information, or for local discovery purposes.</p> 506 </dd> 507 </dl> 508 </li> 509 </ul> 510 <p>To communicate with a <em>single</em> destination, you need to know its public key. Any method for 511 obtaining the public key is valid, but Reticulum includes a simple mechanism for making other 512 nodes aware of your destinations public key, called the <em>announce</em>. It is also possible to request 513 an unknown public key from the network, as all transport instances serve as a distributed ledger 514 of public keys.</p> 515 <p>Note that public key information can be shared and verified in other ways than using the 516 built-in <em>announce</em> functionality, and that it is therefore not required to use the <em>announce</em> and <em>path request</em> 517 functionality to obtain public keys. It is by far the easiest though, and should definitely be used 518 if there is not a very good reason for doing it differently.</p> 519 </section> 520 </section> 521 <section id="public-key-announcements"> 522 <span id="understanding-keyannouncements"></span><h3>Public Key Announcements<a class="headerlink" href="#public-key-announcements" title="Link to this heading">¶</a></h3> 523 <p>An <em>announce</em> will send a special packet over any relevant interfaces, containing all needed 524 information about the destination hash and public key, and can also contain some additional, 525 application specific data. The entire packet is signed by the sender to ensure authenticity. It is not 526 required to use the announce functionality, but in many cases it will be the simplest way to share 527 public keys on the network. The announce mechanism also serves to establish end-to-end connectivity 528 to the announced destination, as the announce propagates through the network.</p> 529 <p>As an example, an announce in a simple messenger application might contain the following information:</p> 530 <ul class="simple"> 531 <li><p>The announcers destination hash</p></li> 532 <li><p>The announcers public key</p></li> 533 <li><p>Application specific data, in this case the users nickname and availability status</p></li> 534 <li><p>A random blob, making each new announce unique</p></li> 535 <li><p>An Ed25519 signature of the above information, verifying authenticity</p></li> 536 </ul> 537 <p>With this information, any Reticulum node that receives it will be able to reconstruct an outgoing 538 destination to securely communicate with that destination. You might have noticed that there is one 539 piece of information lacking to reconstruct full knowledge of the announced destination, and that is 540 the aspect names of the destination. These are intentionally left out to save bandwidth, since they 541 will be implicit in almost all cases. The receiving application will already know them. If a destination 542 name is not entirely implicit, information can be included in the application specific data part that 543 will allow the receiver to infer the naming.</p> 544 <p>It is important to note that announces will be forwarded throughout the network according to a 545 certain pattern. This will be detailed in the section 546 <a class="reference internal" href="#understanding-announce"><span class="std std-ref">The Announce Mechanism in Detail</span></a>.</p> 547 <p>In Reticulum, destinations are allowed to move around the network at will. This is very different from 548 protocols such as IP, where an address is always expected to stay within the network segment it was assigned in. 549 This limitation does not exist in Reticulum, and any destination is <em>completely portable</em> over the entire topography 550 of the network, and <em>can even be moved to other Reticulum networks</em> than the one it was created in, and 551 still become reachable. To update its reachability, a destination simply needs to send an announce on any 552 networks it is part of. After a short while, it will be globally reachable in the network.</p> 553 <p>Seeing how <em>single</em> destinations are always tied to a private/public key pair leads us to the next topic.</p> 554 </section> 555 <section id="understanding-identities"> 556 <span id="identities"></span><h3>Identities<a class="headerlink" href="#understanding-identities" title="Link to this heading">¶</a></h3> 557 <p>In Reticulum, an <em>identity</em> does not necessarily represent a personal identity, but is an abstraction that 558 can represent any kind of <em>verifiable entity</em>. This could very well be a person, but it could also be the 559 control interface of a machine, a program, robot, computer, sensor or something else entirely. In 560 general, any kind of agent that can act, or be acted upon, or store or manipulate information, can be 561 represented as an identity. An <em>identity</em> can be used to create any number of destinations.</p> 562 <p>A <em>single</em> destination will always have an <em>identity</em> tied to it, but not <em>plain</em> or <em>group</em> 563 destinations. Destinations and identities share a multilateral connection. You can create a 564 destination, and if it is not connected to an identity upon creation, it will just create a new one to use 565 automatically. This may be desirable in some situations, but often you will probably want to create 566 the identity first, and then use it to create new destinations.</p> 567 <p>As an example, we could use an identity to represent the user of a messaging application. 568 Destinations can then be created by this identity to allow communication to reach the user. 569 In all cases it is of great importance to store the private keys associated with any 570 Reticulum Identity securely and privately, since obtaining access to the identity keys equals 571 obtaining access and controlling reachability to any destinations created by that identity.</p> 572 </section> 573 <section id="getting-further"> 574 <span id="understanding-gettingfurther"></span><h3>Getting Further<a class="headerlink" href="#getting-further" title="Link to this heading">¶</a></h3> 575 <p>The above functions and principles form the core of Reticulum, and would suffice to create 576 functional networked applications in local clusters, for example over radio links where all interested 577 nodes can directly hear each other. But to be truly useful, we need a way to direct traffic over multiple 578 hops in the network.</p> 579 <p>In the following sections, two concepts that allow this will be introduced, <em>paths</em> and <em>links</em>.</p> 580 </section> 581 </section> 582 <section id="reticulum-transport"> 583 <span id="understanding-transport"></span><h2>Reticulum Transport<a class="headerlink" href="#reticulum-transport" title="Link to this heading">¶</a></h2> 584 <p>The methods of routing used in traditional networks are fundamentally incompatible with the physical medium 585 types and circumstances that Reticulum was designed to handle. These mechanisms mostly assume trust at the physical layer, 586 and often needs a lot more bandwidth than Reticulum can assume is available. Since Reticulum is designed to 587 survive running over open radio spectrum, no such trust can be assumed, and bandwidth is often very limited.</p> 588 <p>To overcome such challenges, Reticulum’s <em>Transport</em> system uses asymmetric elliptic curve cryptography to 589 implement the concept of <em>paths</em> that allow discovery of how to get information closer to a certain 590 destination. It is important to note that no single node in a Reticulum network knows the complete 591 path to a destination. Every Transport node participating in a Reticulum network will only 592 know the most direct way to get a packet one hop closer to it’s destination.</p> 593 <section id="node-types"> 594 <span id="understanding-nodetypes"></span><h3>Node Types<a class="headerlink" href="#node-types" title="Link to this heading">¶</a></h3> 595 <p>Currently, Reticulum distinguishes between two types of network nodes. All nodes on a Reticulum network 596 are <em>Reticulum Instances</em>, and some are also <em>Transport Nodes</em>. If a system running Reticulum is fixed in 597 one place, and is intended to be kept available most of the time, it is a good contender to be a <em>Transport Node</em>.</p> 598 <p>Any Reticulum Instance can become a Transport Node by enabling it in the configuration. 599 This distinction is made by the user configuring the node, and is used to determine what nodes on the 600 network will help forward traffic, and what nodes rely on other nodes for wider connectivity.</p> 601 <p>If a node is an <em>Instance</em> it should be given the configuration directive <code class="docutils literal notranslate"><span class="pre">enable_transport</span> <span class="pre">=</span> <span class="pre">No</span></code>, which 602 is the default setting.</p> 603 <p>If it is a <em>Transport Node</em>, it should be given the configuration directive <code class="docutils literal notranslate"><span class="pre">enable_transport</span> <span class="pre">=</span> <span class="pre">Yes</span></code>.</p> 604 </section> 605 <section id="the-announce-mechanism-in-detail"> 606 <span id="understanding-announce"></span><h3>The Announce Mechanism in Detail<a class="headerlink" href="#the-announce-mechanism-in-detail" title="Link to this heading">¶</a></h3> 607 <p>When an <em>announce</em> for a destination is transmitted by a Reticulum instance, it will be forwarded by 608 any transport node receiving it, but according to some specific rules:</p> 609 <ul> 610 <li><div class="line-block"> 611 <div class="line">If this exact announce has already been received before, ignore it.</div> 612 </div> 613 </li> 614 <li><div class="line-block"> 615 <div class="line">If not, record into a table which Transport Node the announce was received from, and how many times in 616 total it has been retransmitted to get here.</div> 617 </div> 618 </li> 619 <li><div class="line-block"> 620 <div class="line">If the announce has been retransmitted <em>m+1</em> times, it will not be forwarded any more. By default, <em>m</em> is 621 set to 128.</div> 622 </div> 623 </li> 624 <li><div class="line-block"> 625 <div class="line">After a randomised delay, the announce will be retransmitted on all interfaces that have bandwidth 626 available for processing announces. By default, the maximum bandwidth allocation for processing 627 announces is set at 2%, but can be configured on a per-interface basis.</div> 628 </div> 629 </li> 630 <li><div class="line-block"> 631 <div class="line">If any given interface does not have enough bandwidth available for retransmitting the announce, 632 the announce will be assigned a priority inversely proportional to its hop count, and be inserted 633 into a queue managed by the interface.</div> 634 </div> 635 </li> 636 <li><div class="line-block"> 637 <div class="line">When the interface has bandwidth available for processing an announce, it will prioritise announces 638 for destinations that are closest in terms of hops, thus prioritising reachability and connectivity 639 of local nodes, even on slow networks that connect to wider and faster networks.</div> 640 </div> 641 </li> 642 <li><div class="line-block"> 643 <div class="line">After the announce has been re-transmitted, and if no other nodes are heard retransmitting the announce 644 with a greater hop count than when it left this node, transmitting it will be retried <em>r</em> times. By default, 645 <em>r</em> is set to 1.</div> 646 </div> 647 </li> 648 <li><div class="line-block"> 649 <div class="line">If a newer announce from the same destination arrives, while an identical one is already waiting 650 to be transmitted, the newest announce is discarded. If the newest announce contains different 651 application specific data, it will replace the old announce.</div> 652 </div> 653 </li> 654 </ul> 655 <p>Once an announce has reached a transport node in the network, any other node in direct contact with that 656 transport node will be able to reach the destination the announce originated from, simply by sending a packet 657 addressed to that destination. Any transport node with knowledge of the announce will be able to direct the 658 packet towards the destination by looking up the most efficient next node to the destination.</p> 659 <p>According to these rules, an announce will propagate throughout the network in a predictable way, 660 and make the announced destination reachable in a short amount of time. Fast networks that have the 661 capacity to process many announces can reach full convergence very quickly, even when constantly adding 662 new destinations. Slower segments of such networks might take a bit longer to gain full knowledge about 663 the wide and fast networks they are connected to, but can still do so over time, while prioritising full 664 and quickly converging end-to-end connectivity for their local, slower segments.</p> 665 <div class="admonition tip"> 666 <p class="admonition-title">Tip</p> 667 <p>Even very slow networks, that simply don’t have the capacity to ever reach <em>full</em> convergence 668 will generally still be able to reach <strong>any other destination on any connected segments</strong>, since 669 interconnecting transport nodes will prioritize announces into the slower segments that are 670 actually requested by nodes on these.</p> 671 <p>This means that slow, low-capacity or low-resource segments <strong>don’t</strong> need to have full network 672 knowledge, since paths can always be recursively resolved from other segments that do have 673 knowledge about them.</p> 674 </div> 675 <p>In general, even extremely complex networks, that utilize the maximum 128 hops will converge to full 676 end-to-end connectivity in about one minute, given there is enough bandwidth available to process 677 the required amount of announces.</p> 678 </section> 679 <section id="reaching-the-destination"> 680 <span id="understanding-paths"></span><h3>Reaching the Destination<a class="headerlink" href="#reaching-the-destination" title="Link to this heading">¶</a></h3> 681 <p>In networks with changing topology and trustless connectivity, nodes need a way to establish 682 <em>verified connectivity</em> with each other. Since the underlying network mediums are assumed to be trustless, Reticulum 683 must provide a way to guarantee that the peer you are communicating with is actually who you 684 expect. Reticulum offers two ways to do this.</p> 685 <p>For exchanges of small amounts of information, Reticulum offers the <em>Packet</em> API, which works exactly like you would expect - on a per packet level. The following process is employed when sending a packet:</p> 686 <ul> 687 <li><div class="line-block"> 688 <div class="line">A packet is always created with an associated destination and some payload data. When the packet is sent 689 to a <em>single</em> destination type, Reticulum will automatically create an ephemeral encryption key, perform 690 an ECDH key exchange with the destination’s public key (or ratchet key, if available), and encrypt the information.</div> 691 </div> 692 </li> 693 <li><div class="line-block"> 694 <div class="line">It is important to note that this key exchange does not require any network traffic. The sender already 695 knows the public key of the destination from an earlier received announce, and can thus perform the ECDH 696 key exchange locally, before sending the packet.</div> 697 </div> 698 </li> 699 <li><div class="line-block"> 700 <div class="line">The public part of the newly generated ephemeral key-pair is included with the encrypted token, and sent 701 along with the encrypted payload data in the packet.</div> 702 </div> 703 </li> 704 <li><div class="line-block"> 705 <div class="line">When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the 706 packet.</div> 707 </div> 708 </li> 709 <li><div class="line-block"> 710 <div class="line">A new ephemeral key is used for every packet sent in this way.</div> 711 </div> 712 </li> 713 <li><div class="line-block"> 714 <div class="line">Once the packet has been received and decrypted by the addressed destination, that destination can opt 715 to <em>prove</em> its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet, 716 and signing this hash with its Ed25519 signing key. Transport nodes in the network can then direct this 717 <em>proof</em> back to the packets origin, where the signature can be verified against the destination’s known 718 public signing key.</div> 719 </div> 720 </li> 721 <li><div class="line-block"> 722 <div class="line">In case the packet is addressed to a <em>group</em> destination type, the packet will be encrypted with the 723 pre-shared AES-256 key associated with the destination. In case the packet is addressed to a <em>plain</em> 724 destination type, the payload data will not be encrypted. Neither of these two destination types can offer 725 forward secrecy. In general, it is recommended to always use the <em>single</em> destination type, unless it is 726 strictly necessary to use one of the others.</div> 727 </div> 728 </li> 729 </ul> 730 <p>For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the <em>Link</em> API. To establish a <em>link</em>, the following process is employed:</p> 731 <ul> 732 <li><div class="line-block"> 733 <div class="line">First, the node that wishes to establish a link will send out a <em>link request</em> packet, that 734 traverses the network and locates the desired destination. Along the way, the Transport Nodes that 735 forward the packet will take note of this <em>link request</em>, and mark it as pending.</div> 736 </div> 737 </li> 738 <li><div class="line-block"> 739 <div class="line">Second, if the destination accepts the <em>link request</em> , it will send back a packet that proves the 740 authenticity of its identity (and the receipt of the link request) to the initiating node. All 741 nodes that initially forwarded the packet will also be able to verify this proof, and thus 742 accept the validity of the <em>link</em> throughout the network. The link is now marked as <em>established</em>.</div> 743 </div> 744 </li> 745 <li><div class="line-block"> 746 <div class="line">When the validity of the <em>link</em> has been accepted by forwarding nodes, these nodes will 747 remember the <em>link</em> , and it can subsequently be used by referring to a hash representing it.</div> 748 </div> 749 </li> 750 <li><div class="line-block"> 751 <div class="line">As a part of the <em>link request</em>, an Elliptic Curve Diffie-Hellman key exchange takes place, that sets up an 752 efficiently encrypted tunnel between the two nodes. As such, this mode of communication is preferred, 753 even for situations when nodes can directly communicate, when the amount of data to be exchanged numbers 754 in the tens of packets, or whenever the use of the more advanced API functions is desired.</div> 755 </div> 756 </li> 757 <li><div class="line-block"> 758 <div class="line">When a <em>link</em> has been set up, it automatically provides message receipt functionality, through 759 the same <em>proof</em> mechanism discussed before, so the sending node can obtain verified confirmation 760 that the information reached the intended recipient.</div> 761 </div> 762 </li> 763 <li><div class="line-block"> 764 <div class="line">Once the <em>link</em> has been set up, the initiator can remain anonymous, or choose to authenticate towards 765 the destination using a Reticulum Identity. This authentication is happening inside the encrypted 766 link, and is only revealed to the verified destination, and no intermediaries.</div> 767 </div> 768 </li> 769 </ul> 770 <p>In a moment, we will discuss the details of how this methodology is 771 implemented, but let’s first recap what purposes this methodology serves. We 772 first ensure that the node answering our request is actually the one we want to 773 communicate with, and not a malicious actor pretending to be so. At the same 774 time we establish an efficient encrypted channel. The setup of this is 775 relatively cheap in terms of bandwidth, so it can be used just for a short 776 exchange, and then recreated as needed, which will also rotate encryption keys. 777 The link can also be kept alive for longer periods of time, if this is more 778 suitable to the application. The procedure also inserts the <em>link id</em> , a hash 779 calculated from the link request packet, into the memory of forwarding nodes, 780 which means that the communicating nodes can thereafter reach each other simply 781 by referring to this <em>link id</em>.</p> 782 <p>The combined bandwidth cost of setting up a link is 3 packets totalling 297 bytes (more info in the 783 <a class="reference internal" href="#understanding-packetformat"><span class="std std-ref">Binary Packet Format</span></a> section). The amount of bandwidth used on keeping 784 a link open is practically negligible, at 0.45 bits per second. Even on a slow 1200 bits per second packet 785 radio channel, 100 concurrent links will still leave 96% channel capacity for actual data.</p> 786 <section id="link-establishment-in-detail"> 787 <h4>Link Establishment in Detail<a class="headerlink" href="#link-establishment-in-detail" title="Link to this heading">¶</a></h4> 788 <p>After exploring the basics of the announce mechanism, finding a path through the network, and an overview 789 of the link establishment procedure, this section will go into greater detail about the Reticulum link 790 establishment process.</p> 791 <p>The <em>link</em> in Reticulum terminology should not be viewed as a direct node-to-node link on the 792 physical layer, but as an abstract channel, that can be open for any amount of time, and can span 793 an arbitrary number of hops, where information will be exchanged between two nodes.</p> 794 <ul> 795 <li><div class="line-block"> 796 <div class="line">When a node in the network wants to establish verified connectivity with another node, it 797 will randomly generate a new X25519 private/public key pair. It then creates a <em>link request</em> 798 packet, and broadcast it.</div> 799 <div class="line"><br /></div> 800 <div class="line"><em>It should be noted that the X25519 public/private keypair mentioned above is two separate keypairs: 801 An encryption key pair, used for derivation of a shared symmetric key, and a signing key pair, used 802 for signing and verifying messages on the link. They are sent together over the wire, and can be 803 considered as single public key for simplicity in this explanation.</em></div> 804 </div> 805 </li> 806 <li><div class="line-block"> 807 <div class="line">The <em>link request</em> is addressed to the destination hash of the desired destination, and 808 contains the following data: The newly generated X25519 public key <em>LKi</em>.</div> 809 </div> 810 </li> 811 <li><div class="line-block"> 812 <div class="line">The broadcasted packet will be directed through the network according to the rules laid out 813 previously.</div> 814 </div> 815 </li> 816 <li><div class="line-block"> 817 <div class="line">Any node that forwards the link request will store a <em>link id</em> in it’s <em>link table</em> , along with the 818 amount of hops the packet had taken when received. The link id is a hash of the entire link 819 request packet. If the link request packet is not <em>proven</em> by the addressed destination within some 820 set amount of time, the entry will be dropped from the <em>link table</em> again.</div> 821 </div> 822 </li> 823 <li><div class="line-block"> 824 <div class="line">When the destination receives the link request packet, it will decide whether to accept the request. 825 If it is accepted, the destination will also generate a new X25519 private/public key pair, and 826 perform a Diffie Hellman Key Exchange, deriving a new symmetric key that will be used to encrypt the 827 channel, once it has been established.</div> 828 </div> 829 </li> 830 <li><div class="line-block"> 831 <div class="line">A <em>link proof</em> packet is now constructed and transmitted over the network. This packet is 832 addressed to the <em>link id</em> of the <em>link</em>. It contains the following data: The newly generated X25519 833 public key <em>LKr</em> and an Ed25519 signature of the <em>link id</em> and <em>LKr</em> made by the <em>original signing key</em> of 834 the addressed destination.</div> 835 </div> 836 </li> 837 <li><div class="line-block"> 838 <div class="line">By verifying this <em>link proof</em> packet, all nodes that originally transported the <em>link request</em> 839 packet to the destination from the originator can now verify that the intended destination received 840 the request and accepted it, and that the path they chose for forwarding the request was valid. 841 In successfully carrying out this verification, the transporting nodes marks the link as active. 842 An abstract bi-directional communication channel has now been established along a path in the network. 843 Packets can now be exchanged bi-directionally from either end of the link simply by adressing the 844 packets to the <em>link id</em> of the link.</div> 845 </div> 846 </li> 847 <li><div class="line-block"> 848 <div class="line">When the source receives the <em>proof</em> , it will know unequivocally that a verified path has been 849 established to the destination. It can now also use the X25519 public key contained in the 850 <em>link proof</em> to perform it’s own Diffie Hellman Key Exchange and derive the symmetric key 851 that is used to encrypt the channel. Information can now be exchanged reliably and securely.</div> 852 </div> 853 </li> 854 </ul> 855 <div class="admonition note"> 856 <p class="admonition-title">Note</p> 857 <p>It’s important to note that this methodology ensures that the source of the request does not need to 858 reveal any identifying information about itself. <strong>The link initiator remains completely anonymous</strong>.</p> 859 </div> 860 <p>When using <em>links</em>, Reticulum will automatically verify all data sent over the link, and can also 861 automate retransmissions if <em>Resources</em> are used.</p> 862 </section> 863 </section> 864 <section id="resources"> 865 <span id="understanding-resources"></span><h3>Resources<a class="headerlink" href="#resources" title="Link to this heading">¶</a></h3> 866 <p>For exchanging small amounts of data over a Reticulum network, the <a class="reference internal" href="reference.html#api-packet"><span class="std std-ref">Packet</span></a> interface 867 is sufficient, but for exchanging data that would require many packets, an efficient way to coordinate 868 the transfer is needed.</p> 869 <p>This is the purpose of the Reticulum <a class="reference internal" href="reference.html#api-resource"><span class="std std-ref">Resource</span></a>. A <em>Resource</em> can automatically 870 handle the reliable transfer of an arbitrary amount of data over an established <a class="reference internal" href="reference.html#api-link"><span class="std std-ref">Link</span></a>. 871 Resources can auto-compress data, will handle breaking the data into individual packets, sequencing 872 the transfer, integrity verification and reassembling the data on the other end.</p> 873 <p><a class="reference internal" href="reference.html#api-resource"><span class="std std-ref">Resources</span></a> are programmatically very simple to use, and only requires a few lines 874 of codes to reliably transfer any amount of data. They can be used to transfer data stored in memory, 875 or stream data directly from files.</p> 876 </section> 877 </section> 878 <section id="network-identities"> 879 <span id="understanding-network-identities"></span><h2>Network Identities<a class="headerlink" href="#network-identities" title="Link to this heading">¶</a></h2> 880 <p>In Reticulum, every peer and application utilizes a cryptographic <strong>Identity</strong> to verify authenticity and establish encrypted channels. While standard identities are typically used to represent a single user, device, or service, Reticulum introduces the concept of a <strong>Network Identity</strong> to represent a logical group of nodes or an entire community infrastructure.</p> 881 <p>A Network Identity is, at its core, a standard Reticulum Identity keyset. However, its purpose and usage differ from a personal identity. Instead of identifying a single entity, a Network Identity acts as a shared credential that federates multiple independent Transport Instances under a single, verifiable administrative domain.</p> 882 <section id="conceptual-overview"> 883 <h3>Conceptual Overview<a class="headerlink" href="#conceptual-overview" title="Link to this heading">¶</a></h3> 884 <p>You can think of a standard Reticulum Identity as a self-sovereign, privately created passport for a single person. A Network Identity, conversely, is akin to a cryptographic flag, or a charter that flies over a fleet of ships. It signifies that while the ships may operate independently and be physically distant, they belong to the same organization, follow the same protocols, and are expected to act in concert.</p> 885 <p>When you configure a Network Identity on one or more of your nodes, you are effectively declaring that these nodes constitute a specific “network” within a broader Reticulum mesh. This allows other peers to recognize interfaces not just as “a node named Alice”, but as “a gateway belonging to The Eastern Ret Of Freedom”.</p> 886 </section> 887 <section id="current-usage"> 888 <h3>Current Usage<a class="headerlink" href="#current-usage" title="Link to this heading">¶</a></h3> 889 <p>At present, the primary function of a Network Identity is within the <a class="reference internal" href="using.html#using-interface-discovery"><span class="std std-ref">Interface Discovery</span></a> system.</p> 890 <p>When a Transport Instance broadcasts a discovery announce for an interface, it can optionally sign that announce with a Network Identity, instead of just its local transport identity. Remote peers receiving the announce can then verify the signature. This provides functionality for two important distinctions:</p> 891 <ol class="arabic simple"> 892 <li><p><strong>Authenticity:</strong> It proves that the interface was published by an operator who possesses the private key for that Network Identity.</p></li> 893 <li><p><strong>Trust Boundaries:</strong> It allows users to configure their systems to only accept and connect to interfaces that belong to specific Network Identities, effectively creating “whitelisted” zones of trusted infrastructure.</p></li> 894 </ol> 895 <div class="admonition note"> 896 <p class="admonition-title">Note</p> 897 <p>If you enable encryption on your discovery announces, the Network Identity is used as the shared secret. Only peers who have been explicitly provided with the Network Identity’s full keyset (and have it configured locally) will be able to decrypt and utilize the connection details.</p> 898 <p>This functionality will be expanded in the future, so that peers with delegated keys can be allowed to decrypt discovery announces without holding the root network key. Currently, the functionality is sufficient for sharing interface information privately where you control all nodes that must decrypt the discovered interfaces.</p> 899 </div> 900 </section> 901 <section id="future-implications"> 902 <h3>Future Implications<a class="headerlink" href="#future-implications" title="Link to this heading">¶</a></h3> 903 <p>While the current implementation focuses on interface discovery, the concept of Network Identities serves as the foundational building block for future Reticulum features designed to support large-scale, organic mesh formation.</p> 904 <p>As the ecosystem evolves, Network Identities will facilitate:</p> 905 <ul class="simple"> 906 <li><p><strong>Distributed Name Resolution:</strong> A system where networks can publish name-to-identity mappings, allowing human-readable names to resolve without centralized servers.</p></li> 907 <li><p><strong>Service Publishing:</strong> Networks will be able to announce specific capabilities, services, or information endpoints available publicly or to their members.</p></li> 908 <li><p><strong>Inter-Network Federation:</strong> Trust relationships between different networks, allowing for seamless but managed flow of traffic and information across distinct administrative boundaries.</p></li> 909 <li><p><strong>Distributed Blackhole Management:</strong> A reputation-based system for blackhole list distribution, where trusted Network Identities can sign and publish lists of blackholed identities. This allows communities to collaboratively enforce security standards and filter spam or malicious identities across the parts of the wider mesh that they are responsible for.</p></li> 910 </ul> 911 <p>By adopting the use of Network Identities now, you are preparing your infrastructure to be compatible with this future functionality.</p> 912 </section> 913 <section id="creating-and-using-a-network-identity"> 914 <h3>Creating and Using a Network Identity<a class="headerlink" href="#creating-and-using-a-network-identity" title="Link to this heading">¶</a></h3> 915 <p>Since a Network Identity is simply a standard Reticulum Identity, you create one using the built-in tools.</p> 916 <ol class="arabic"> 917 <li><p><strong>Generate the Identity:</strong> 918 Use the <code class="docutils literal notranslate"><span class="pre">rnid</span></code> utility to generate a new identity file that will serve as your Network Identity.</p> 919 <div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>$<span class="w"> </span>rnid<span class="w"> </span>-g<span class="w"> </span>~/.reticulum/storage/identities/my_network 920 </pre></div> 921 </div> 922 </li> 923 <li><p><strong>Distribute the Public Key:</strong> 924 The public key must be distributed to any Transport Instance that needs to verify your network’s announces and discovery information. By default, if your node is set up to use a network identity, this happens automatically (using the standard announce mechanism).</p></li> 925 <li><p><strong>Configure Instances:</strong> 926 In the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of the configuration file on every node within your network, point the <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> option to the file you created.</p> 927 <div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[reticulum]</span> 928 <span class="na">...</span> 929 <span class="na">network_identity</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">~/.reticulum/storage/identities/my_network</span> 930 <span class="na">...</span> 931 </pre></div> 932 </div> 933 </li> 934 </ol> 935 <p>Once configured, your instances will automatically utilize this identity for signing discovery announces (and potentially decrypting network-private information), presenting a unified front to the wider network.</p> 936 </section> 937 </section> 938 <section id="reference-setup"> 939 <span id="understanding-referencesystem"></span><h2>Reference Setup<a class="headerlink" href="#reference-setup" title="Link to this heading">¶</a></h2> 940 <p>This section will detail a recommended <em>Reference Setup</em> for Reticulum. It is important to 941 note that Reticulum is designed to be usable on more or less any computing device, and over more 942 or less any medium that allows you to send and receive data, which satisfies some very low 943 minimum requirements.</p> 944 <p>The communication channel must support at least half-duplex operation, and provide an average 945 throughput of 5 bits per second or greater, and supports a physical layer MTU of 500 bytes. The 946 Reticulum stack should be able to run on more or less any hardware that can provide a Python 3.x 947 runtime environment.</p> 948 <p>That being said, this reference setup has been outlined to provide a common platform for anyone 949 who wants to help in the development of Reticulum, and for everyone who wants to know a 950 recommended setup to get started experimenting. A reference system consists of three parts:</p> 951 <ul class="simple"> 952 <li><dl class="simple"> 953 <dt><strong>An Interface Device</strong></dt><dd><p>Which provides access to the physical medium whereupon the communication 954 takes place, for example a radio with an integrated modem. A setup with a separate modem 955 connected to a radio would also be an interface device.</p> 956 </dd> 957 </dl> 958 </li> 959 <li><dl class="simple"> 960 <dt><strong>A Host Device</strong></dt><dd><p>Some sort of computing device that can run the necessary software, communicate with the 961 interface device, and provide user interaction.</p> 962 </dd> 963 </dl> 964 </li> 965 <li><dl class="simple"> 966 <dt><strong>A Software Stack</strong></dt><dd><p>The software implementing the Reticulum protocol and applications using it.</p> 967 </dd> 968 </dl> 969 </li> 970 </ul> 971 <p>The reference setup can be considered a relatively stable platform to develop on, and also to start 972 building networks or applications on. While details of the implementation might change at the current stage of 973 development, it is the goal to maintain hardware compatibility for as long as entirely possible, and 974 the current reference setup has been determined to provide a functional platform for many years 975 into the future. The current Reference System Setup is as follows:</p> 976 <ul class="simple"> 977 <li><dl class="simple"> 978 <dt><strong>Interface Device</strong></dt><dd><p>A data radio consisting of a LoRa radio module, and a microcontroller with open source 979 firmware, that can connect to host devices via USB. It operates in either the 430, 868 or 900 980 MHz frequency bands. More details can be found on the <a class="reference external" href="https://github.com/markqvist/rnode_firmware">RNode Page</a>.</p> 981 </dd> 982 </dl> 983 </li> 984 <li><dl class="simple"> 985 <dt><strong>Host Device</strong></dt><dd><p>Any computer device running Linux and Python. A Raspberry Pi with a Debian based OS is 986 a good place to start, but anything can be used.</p> 987 </dd> 988 </dl> 989 </li> 990 <li><dl class="simple"> 991 <dt><strong>Software Stack</strong></dt><dd><p>The most recently released Python Implementation of Reticulum, running on a Linux-based 992 operating system.</p> 993 </dd> 994 </dl> 995 </li> 996 </ul> 997 <div class="admonition note"> 998 <p class="admonition-title">Note</p> 999 <p>To avoid confusion, it is very important to note, that the reference interface device <strong>does not</strong> 1000 use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will 1001 need a plain LoRa radio module connected to a controller with the correct firmware. Full details on how to 1002 get or make such a device is available on the <a class="reference external" href="https://github.com/markqvist/rnode_firmware">RNode Page</a>.</p> 1003 </div> 1004 <p>With the current reference setup, it should be possible to get on a Reticulum network for around 100$ 1005 even if you have none of the hardware already, and need to purchase everything.</p> 1006 <p>This reference setup is of course just a recommendation for getting started easily, and you should 1007 tailor it to your own specific needs, or whatever hardware you have available.</p> 1008 </section> 1009 <section id="protocol-specifics"> 1010 <span id="understanding-protocolspecifics"></span><h2>Protocol Specifics<a class="headerlink" href="#protocol-specifics" title="Link to this heading">¶</a></h2> 1011 <p>This chapter will detail protocol specific information that is essential to the implementation of 1012 Reticulum, but non-critical in understanding how the protocol works on a general level. It should be 1013 treated more as a reference than as essential reading.</p> 1014 <section id="packet-prioritisation"> 1015 <h3>Packet Prioritisation<a class="headerlink" href="#packet-prioritisation" title="Link to this heading">¶</a></h3> 1016 <p>Currently, Reticulum is completely priority-agnostic regarding <em>general</em> traffic. All traffic is handled 1017 on a first-come, first-serve basis. Announce re-transmission and other maintenance traffic is handled 1018 according to the re-transmission times and priorities described earlier in this chapter.</p> 1019 </section> 1020 <section id="interface-access-codes"> 1021 <h3>Interface Access Codes<a class="headerlink" href="#interface-access-codes" title="Link to this heading">¶</a></h3> 1022 <p>Reticulum can create named virtual networks, and networks that are only accessible by knowing a preshared 1023 passphrase. The configuration of this is detailed in the <a class="reference internal" href="interfaces.html#interfaces-options"><span class="std std-ref">Common Interface Options</span></a> 1024 section. To implement this feature, Reticulum uses the concept of Interface Access Codes, that are calculated 1025 and verified per-packet.</p> 1026 <p>An interface with a named virtual network or passphrase authentication enabled will derive a shared Ed25519 1027 signing identity, and for every outbound packet generate a signature of the entire packet. This signature is 1028 then inserted into the packet as an Interface Access Code before transmission. Depending on the speed and 1029 capabilities of the interface, the IFAC can be the full 512-bit Ed25519 signature, or a truncated version. 1030 Configured IFAC length can be inspected for all interfaces with the <code class="docutils literal notranslate"><span class="pre">rnstatus</span></code> utility.</p> 1031 <p>Upon receipt, the interface will check that the signature matches the expected value, and drop the packet if it 1032 does not. This ensures that only packets sent with the correct naming and/or passphrase parameters are allowed to 1033 pass onto the network.</p> 1034 </section> 1035 <section id="wire-format"> 1036 <span id="understanding-packetformat"></span><h3>Wire Format<a class="headerlink" href="#wire-format" title="Link to this heading">¶</a></h3> 1037 <div class="highlight-text notranslate"><div class="highlight"><pre><span></span>== Reticulum Wire Format ====== 1038 1039 A Reticulum packet is composed of the following fields: 1040 1041 [HEADER 2 bytes] [ADDRESSES 16/32 bytes] [CONTEXT 1 byte] [DATA 0-465 bytes] 1042 1043 * The HEADER field is 2 bytes long. 1044 * Byte 1: [IFAC Flag], [Header Type], [Context Flag], [Propagation Type], 1045 [Destination Type] and [Packet Type] 1046 * Byte 2: Number of hops 1047 1048 * Interface Access Code field if the IFAC flag was set. 1049 * The length of the Interface Access Code can vary from 1050 1 to 64 bytes according to physical interface 1051 capabilities and configuration. 1052 1053 * The ADDRESSES field contains either 1 or 2 addresses. 1054 * Each address is 16 bytes long. 1055 * The Header Type flag in the HEADER field determines 1056 whether the ADDRESSES field contains 1 or 2 addresses. 1057 * Addresses are SHA-256 hashes truncated to 16 bytes. 1058 1059 * The CONTEXT field is 1 byte. 1060 * It is used by Reticulum to determine packet context. 1061 1062 * The DATA field is between 0 and 465 bytes. 1063 * It contains the packets data payload. 1064 1065 IFAC Flag 1066 ----------------- 1067 open 0 Packet for publically accessible interface 1068 authenticated 1 Interface authentication is included in packet 1069 1070 1071 Header Types 1072 ----------------- 1073 type 1 0 Two byte header, one 16 byte address field 1074 type 2 1 Two byte header, two 16 byte address fields 1075 1076 1077 Context Flag 1078 ----------------- 1079 unset 0 The context flag is used for various types 1080 set 1 of signalling, depending on packet context 1081 1082 1083 Propagation Types 1084 ----------------- 1085 broadcast 0 1086 transport 1 1087 1088 1089 Destination Types 1090 ----------------- 1091 single 00 1092 group 01 1093 plain 10 1094 link 11 1095 1096 1097 Packet Types 1098 ----------------- 1099 data 00 1100 announce 01 1101 link request 10 1102 proof 11 1103 1104 1105 +- Packet Example -+ 1106 1107 HEADER FIELD DESTINATION FIELDS CONTEXT FIELD DATA FIELD 1108 _______|_______ ________________|________________ ________|______ __|_ 1109 | | | | | | | | 1110 01010000 00000100 [HASH1, 16 bytes] [HASH2, 16 bytes] [CONTEXT, 1 byte] [DATA] 1111 || | | | | 1112 || | | | +-- Hops = 4 1113 || | | +------- Packet Type = DATA 1114 || | +--------- Destination Type = SINGLE 1115 || +----------- Propagation Type = TRANSPORT 1116 |+------------- Header Type = HEADER_2 (two byte header, two address fields) 1117 +-------------- Access Codes = DISABLED 1118 1119 1120 +- Packet Example -+ 1121 1122 HEADER FIELD DESTINATION FIELD CONTEXT FIELD DATA FIELD 1123 _______|_______ _______|_______ ________|______ __|_ 1124 | | | | | | | | 1125 00000000 00000111 [HASH1, 16 bytes] [CONTEXT, 1 byte] [DATA] 1126 || | | | | 1127 || | | | +-- Hops = 7 1128 || | | +------- Packet Type = DATA 1129 || | +--------- Destination Type = SINGLE 1130 || +----------- Propagation Type = BROADCAST 1131 |+------------- Header Type = HEADER_1 (two byte header, one address field) 1132 +-------------- Access Codes = DISABLED 1133 1134 1135 +- Packet Example -+ 1136 1137 HEADER FIELD IFAC FIELD DESTINATION FIELD CONTEXT FIELD DATA FIELD 1138 _______|_______ ______|______ _______|_______ ________|______ __|_ 1139 | | | | | | | | | | 1140 10000000 00000111 [IFAC, N bytes] [HASH1, 16 bytes] [CONTEXT, 1 byte] [DATA] 1141 || | | | | 1142 || | | | +-- Hops = 7 1143 || | | +------- Packet Type = DATA 1144 || | +--------- Destination Type = SINGLE 1145 || +----------- Propagation Type = BROADCAST 1146 |+------------- Header Type = HEADER_1 (two byte header, one address field) 1147 +-------------- Access Codes = ENABLED 1148 1149 1150 Size examples of different packet types 1151 --------------------------------------- 1152 1153 The following table lists example sizes of various 1154 packet types. The size listed are the complete on- 1155 wire size counting all fields including headers, 1156 but excluding any interface access codes. 1157 1158 - Path Request : 51 bytes 1159 - Announce : 167 bytes 1160 - Link Request : 83 bytes 1161 - Link Proof : 115 bytes 1162 - Link RTT packet : 99 bytes 1163 - Link keepalive : 20 bytes 1164 </pre></div> 1165 </div> 1166 </section> 1167 <section id="announce-propagation-rules"> 1168 <span id="understanding-announcepropagation"></span><h3>Announce Propagation Rules<a class="headerlink" href="#announce-propagation-rules" title="Link to this heading">¶</a></h3> 1169 <p>The following table illustrates the rules for automatically propagating announces 1170 from one interface type to another, for all possible combinations. For the purpose 1171 of announce propagation, the <em>Full</em> and <em>Gateway</em> modes are identical.</p> 1172 <img alt="_images/if_mode_graph_b.png" src="_images/if_mode_graph_b.png" /> 1173 <p>See the <a class="reference internal" href="interfaces.html#interfaces-modes"><span class="std std-ref">Interface Modes</span></a> section for a conceptual overview 1174 of the different interface modes, and how they are configured.</p> 1175 </section> 1176 <section id="cryptographic-primitives"> 1177 <span id="understanding-primitives"></span><h3>Cryptographic Primitives<a class="headerlink" href="#cryptographic-primitives" title="Link to this heading">¶</a></h3> 1178 <p>Reticulum uses a simple suite of efficient, strong and well-tested cryptographic 1179 primitives, with widely available implementations that can be used both on 1180 general-purpose CPUs and on microcontrollers.</p> 1181 <p>One of the primary considerations for choosing this particular set of primitives is 1182 that they can be implemented <em>safely</em> with relatively few pitfalls, on practically 1183 all current computing platforms.</p> 1184 <p>The primitives listed here <strong>are authoritative</strong>. Anything claiming to be Reticulum, 1185 but not using these exact primitives <strong>is not</strong> Reticulum, and possibly an 1186 intentionally compromised or weakened clone. The utilised primitives are:</p> 1187 <ul class="simple"> 1188 <li><p>Ed25519 for signatures</p></li> 1189 <li><p>X25519 for ECDH key exchanges</p></li> 1190 <li><p>HKDF for key derivation</p></li> 1191 <li><p>Encrypted tokens are based on the Fernet spec</p> 1192 <ul> 1193 <li><p>Ephemeral keys derived from an ECDH key exchange on Curve25519</p></li> 1194 <li><p>AES-256 in CBC mode with PKCS7 padding</p></li> 1195 <li><p>HMAC using SHA256 for message authentication</p></li> 1196 <li><p>IVs must be generated through <code class="docutils literal notranslate"><span class="pre">os.urandom()</span></code> or better</p></li> 1197 <li><p>No Fernet version and timestamp metadata fields</p></li> 1198 </ul> 1199 </li> 1200 <li><p>SHA-256</p></li> 1201 <li><p>SHA-512</p></li> 1202 </ul> 1203 <p>In the default installation configuration, the <code class="docutils literal notranslate"><span class="pre">X25519</span></code>, <code class="docutils literal notranslate"><span class="pre">Ed25519</span></code> and <code class="docutils literal notranslate"><span class="pre">AES-256-CBC</span></code> 1204 primitives are provided by <a class="reference external" href="https://www.openssl.org/">OpenSSL</a> (via the <a class="reference external" href="https://github.com/pyca/cryptography">PyCA/cryptography</a> 1205 package). The hashing functions <code class="docutils literal notranslate"><span class="pre">SHA-256</span></code> and <code class="docutils literal notranslate"><span class="pre">SHA-512</span></code> are provided by the standard 1206 Python <a class="reference external" href="https://docs.python.org/3/library/hashlib.html">hashlib</a>. The <code class="docutils literal notranslate"><span class="pre">HKDF</span></code>, <code class="docutils literal notranslate"><span class="pre">HMAC</span></code>, 1207 <code class="docutils literal notranslate"><span class="pre">Token</span></code> primitives, and the <code class="docutils literal notranslate"><span class="pre">PKCS7</span></code> padding function are always provided by the 1208 following internal implementations:</p> 1209 <ul class="simple"> 1210 <li><p><code class="docutils literal notranslate"><span class="pre">RNS/Cryptography/HKDF.py</span></code></p></li> 1211 <li><p><code class="docutils literal notranslate"><span class="pre">RNS/Cryptography/HMAC.py</span></code></p></li> 1212 <li><p><code class="docutils literal notranslate"><span class="pre">RNS/Cryptography/Token.py</span></code></p></li> 1213 <li><p><code class="docutils literal notranslate"><span class="pre">RNS/Cryptography/PKCS7.py</span></code></p></li> 1214 </ul> 1215 <p>Reticulum also includes a complete implementation of all necessary primitives in pure Python. 1216 If OpenSSL & PyCA are not available on the system when Reticulum is started, Reticulum will 1217 instead use the internal pure-python primitives. A trivial consequence of this is performance, 1218 with the OpenSSL backend being <em>much</em> faster. The most important consequence however, is the 1219 potential loss of security by using primitives that has not seen the same amount of scrutiny, 1220 testing and review as those from OpenSSL.</p> 1221 <p>Using the normal RNS installation procedures, it is not possible to install Reticulum on a 1222 system without the required OpenSSL primitives being available, and if they are not, they will 1223 be resolved and installed as a dependency. It is only possible to use the pure-python primitives 1224 by manually specifying this, for example by using the <code class="docutils literal notranslate"><span class="pre">rnspure</span></code> package.</p> 1225 <div class="admonition warning"> 1226 <p class="admonition-title">Warning</p> 1227 <p>If you want to use the internal pure-python primitives, it is <strong>highly advisable</strong> that you 1228 have a good understanding of the risks that this pose, and make an informed decision on whether 1229 those risks are acceptable to you.</p> 1230 </div> 1231 </section> 1232 </section> 1233 </section> 1234 1235 </article> 1236 </div> 1237 <footer> 1238 1239 <div class="related-pages"> 1240 <a class="next-page" href="hardware.html"> 1241 <div class="page-info"> 1242 <div class="context"> 1243 <span>Next</span> 1244 </div> 1245 <div class="title">Communications Hardware</div> 1246 </div> 1247 <svg class="furo-related-icon"><use href="#svg-arrow-right"></use></svg> 1248 </a> 1249 <a class="prev-page" href="using.html"> 1250 <svg class="furo-related-icon"><use href="#svg-arrow-right"></use></svg> 1251 <div class="page-info"> 1252 <div class="context"> 1253 <span>Previous</span> 1254 </div> 1255 1256 <div class="title">Using Reticulum on Your System</div> 1257 1258 </div> 1259 </a> 1260 </div> 1261 <div class="bottom-of-page"> 1262 <div class="left-details"> 1263 <div class="copyright"> 1264 Copyright © 2025, Mark Qvist 1265 </div> 1266 Generated with <a href="https://www.sphinx-doc.org/">Sphinx</a> and 1267 <a href="https://github.com/pradyunsg/furo">Furo</a> 1268 1269 </div> 1270 <div class="right-details"> 1271 1272 </div> 1273 </div> 1274 1275 </footer> 1276 </div> 1277 <aside class="toc-drawer"> 1278 1279 1280 <div class="toc-sticky toc-scroll"> 1281 <div class="toc-title-container"> 1282 <span class="toc-title"> 1283 On this page 1284 </span> 1285 </div> 1286 <div class="toc-tree-container"> 1287 <div class="toc-tree"> 1288 <ul> 1289 <li><a class="reference internal" href="#">Understanding Reticulum</a><ul> 1290 <li><a class="reference internal" href="#motivation">Motivation</a></li> 1291 <li><a class="reference internal" href="#goals">Goals</a></li> 1292 <li><a class="reference internal" href="#introduction-basic-functionality">Introduction & Basic Functionality</a><ul> 1293 <li><a class="reference internal" href="#destinations">Destinations</a><ul> 1294 <li><a class="reference internal" href="#destination-naming">Destination Naming</a></li> 1295 </ul> 1296 </li> 1297 <li><a class="reference internal" href="#public-key-announcements">Public Key Announcements</a></li> 1298 <li><a class="reference internal" href="#understanding-identities">Identities</a></li> 1299 <li><a class="reference internal" href="#getting-further">Getting Further</a></li> 1300 </ul> 1301 </li> 1302 <li><a class="reference internal" href="#reticulum-transport">Reticulum Transport</a><ul> 1303 <li><a class="reference internal" href="#node-types">Node Types</a></li> 1304 <li><a class="reference internal" href="#the-announce-mechanism-in-detail">The Announce Mechanism in Detail</a></li> 1305 <li><a class="reference internal" href="#reaching-the-destination">Reaching the Destination</a><ul> 1306 <li><a class="reference internal" href="#link-establishment-in-detail">Link Establishment in Detail</a></li> 1307 </ul> 1308 </li> 1309 <li><a class="reference internal" href="#resources">Resources</a></li> 1310 </ul> 1311 </li> 1312 <li><a class="reference internal" href="#network-identities">Network Identities</a><ul> 1313 <li><a class="reference internal" href="#conceptual-overview">Conceptual Overview</a></li> 1314 <li><a class="reference internal" href="#current-usage">Current Usage</a></li> 1315 <li><a class="reference internal" href="#future-implications">Future Implications</a></li> 1316 <li><a class="reference internal" href="#creating-and-using-a-network-identity">Creating and Using a Network Identity</a></li> 1317 </ul> 1318 </li> 1319 <li><a class="reference internal" href="#reference-setup">Reference Setup</a></li> 1320 <li><a class="reference internal" href="#protocol-specifics">Protocol Specifics</a><ul> 1321 <li><a class="reference internal" href="#packet-prioritisation">Packet Prioritisation</a></li> 1322 <li><a class="reference internal" href="#interface-access-codes">Interface Access Codes</a></li> 1323 <li><a class="reference internal" href="#wire-format">Wire Format</a></li> 1324 <li><a class="reference internal" href="#announce-propagation-rules">Announce Propagation Rules</a></li> 1325 <li><a class="reference internal" href="#cryptographic-primitives">Cryptographic Primitives</a></li> 1326 </ul> 1327 </li> 1328 </ul> 1329 </li> 1330 </ul> 1331 1332 </div> 1333 </div> 1334 </div> 1335 1336 1337 </aside> 1338 </div> 1339 </div><script src="_static/documentation_options.js?v=cb7bf70b"></script> 1340 <script src="_static/doctools.js?v=9bcbadda"></script> 1341 <script src="_static/sphinx_highlight.js?v=dc90522c"></script> 1342 <script src="_static/scripts/furo.js?v=46bd48cc"></script> 1343 <script src="_static/clipboard.min.js?v=a7894cd8"></script> 1344 <script src="_static/copybutton.js?v=f281be69"></script> 1345 </body> 1346 </html>