Mirrors
/
Reticulum
mirror of https://github.com/markqvist/Reticulum.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated documentation

This commit is contained in:
Mark Qvist 2021-05-20 16:06:12 +02:00
parent f18fb35aba
commit 9c995b33dd
11 changed files with 132 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -19,7 +19,7 @@ For more info, see [unsigned.io/projects/reticulum](https://unsigned.io/projects
- Coordination-less globally unique adressing and identification - Coordination-less globally unique adressing and identification
- Fully self-configuring multi-hop routing - Fully self-configuring multi-hop routing
- Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication - Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication
- Forward Secrecy with ephemereal Elliptic Curve Diffie-Hellman keys (on Curve25519) - Forward Secrecy with ephemereal Elliptic Curve Diffie-Hellman keys on Curve25519
- Reticulum uses the [Fernet](https://github.com/fernet/spec/blob/master/Spec.md) specification for encryption - Reticulum uses the [Fernet](https://github.com/fernet/spec/blob/master/Spec.md) specification for encryption
- AES-128 in CBC mode with PKCS7 padding - AES-128 in CBC mode with PKCS7 padding
- HMAC using SHA256 for authentication - HMAC using SHA256 for authentication

3
docs/manual/_sources/gettingstartedfast.rst.txt
View File

@ -1,7 +1,6 @@
******************** ********************
Getting Started Fast Getting Started Fast
******************** ********************
What do we want to do? Something! When do we want to do it? Right now! Let's go.
The best way to get started with the Reticulum Network Stack depends on what The best way to get started with the Reticulum Network Stack depends on what
you want to do. This guide will outline sensible starting paths for different you want to do. This guide will outline sensible starting paths for different
@ -23,7 +22,7 @@ in the development for the messaging and information-sharing protocol
Develop a Program with Reticulum Develop a Program with Reticulum
=========================================== ===========================================
If you want to develop programs that use Reticulum, the easiest way to get If you want to develop programs that use Reticulum, the easiest way to get
started is to install Reticulum via pip: started is to install the latest release of Reticulum via pip:
.. code:: .. code::

45
docs/manual/_sources/understanding.rst.txt
View File

@ -308,10 +308,26 @@ Reaching the Destination
In networks with changing topology and trustless connectivity, nodes need a way to establish In networks with changing topology and trustless connectivity, nodes need a way to establish
*verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum *verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum
must provide a way to guarantee that the peer you are communicating with is actually who you must provide a way to guarantee that the peer you are communicating with is actually who you
expect. To do this, the following process is employed: expect. Reticulum offers two ways to do this.
For exchanges of small amounts of information, Reticulum offers the *Packet* API, which works exactly like you would expect - on a per packet level. The following process is employed when sending a packet:
* | A packet is always created with an associated destination and some payload data. When the packet is sent to a *single* destination type, Reticulum will automatically create an ephemeral encryption key, perform an ECDH key exchange with the destinations public key, and encrypt the information.
* | It is important to note that this key exchange does not require any network traffic. The sender already knows the public key of the destination from an earlier received *announce*, and can thus perform the ECDH key exchange locally.
* | The public key part of the newly generated ephemeral key is included with the encrypted token, and sent along with the encrypted payload data in the packet.
* | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the packet.
* | A new ephemeral key is used for every packet sent in this way, and forward secrecy is guaranteed on a per packet level.
* | In case the packet is addressed to a *group* destination type, the packet will be encrypted with the pre-shared AES-128 key associated with the destination. In case the packet is addressed to a *plain* destination type, the payload data will not be encrypted. Neither of these two destination types offer forward secrecy. In general, it is recommended to always use the *single* destination type, unless it is strictly necessary to use one of the others.
* | First, the node that wishes to establish connectivity will send out a special packet, that For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the *Link* API. To establish a *link*, the following process is employed:
* | First, the node that wishes to establish a link will send out a special packet, that
traverses the network and locates the desired destination. Along the way, the nodes that traverses the network and locates the desired destination. Along the way, the nodes that
forward the packet will take note of this *link request*. forward the packet will take note of this *link request*.
@ -333,19 +349,19 @@ expect. To do this, the following process is employed:
sending node can obtain verified confirmation that the information reached the intended sending node can obtain verified confirmation that the information reached the intended
recipient. recipient.
In a moment, we will discuss the specifics of how this methodology is implemented, but let’s first In a moment, we will discuss the details of how this methodology is implemented, but let’s first
recap what purposes this serves. We first ensure that the node answering our request is actually the recap what purposes this methodology serves. We first ensure that the node answering our request
one we want to communicate with, and not a malicious actor pretending to be so. At the same time is actually the one we want to communicate with, and not a malicious actor pretending to be so.
we establish an efficient encrypted channel. The setup of this is relatively cheap in terms of At the same time we establish an efficient encrypted channel. The setup of this is relatively cheap in
bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will also terms of bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will
rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is also rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is
more suitable to the application. The amount of bandwidth used on keeping a link open is practically more suitable to the application. The amount of bandwidth used on keeping a link open is practically
negligible. The procedure also inserts the *link id* , a hash calculated from the link request packet, negligible. The procedure also inserts the *link id* , a hash calculated from the link request packet,
into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each
other simply by referring to this *link id*. other simply by referring to this *link id*.
Step 1: Pathfinding Pathfinding in Detail
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
The pathfinding method builds on the *announce* functionality discussed earlier. When an announce The pathfinding method builds on the *announce* functionality discussed earlier. When an announce
is sent out by a node, it will be forwarded by any node receiving it, but according to some specific is sent out by a node, it will be forwarded by any node receiving it, but according to some specific
@ -392,8 +408,8 @@ distance of *Lavg =* 15 kilometers, an announce will be able to propagate outwar
kilometers in 34 minutes, and a *maximum announce radius* of 270 kilometers in approximately 3 kilometers in 34 minutes, and a *maximum announce radius* of 270 kilometers in approximately 3
days. days.
Step 2: Link Establishment Link Establishment in Detail
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After seeing how the conditions for finding a path through the network are created, we will now After seeing how the conditions for finding a path through the network are created, we will now
explore how two nodes can establish reliable communications over multiple hops. The *link* in explore how two nodes can establish reliable communications over multiple hops. The *link* in
@ -450,6 +466,11 @@ reveal any identifying information about itself. The link initiator remains comp
When using *links*, Reticulum will automatically verify all data sent over the link, and can also When using *links*, Reticulum will automatically verify all data sent over the link, and can also
automate retransmissions if *Resources* are used. automate retransmissions if *Resources* are used.
Proven Delivery
^^^^^^^^^^^^^^^
TODO: Write
.. _understanding-resources: .. _understanding-resources:
Resources Resources

8
docs/manual/_sources/whatis.rst.txt
View File

@ -25,11 +25,11 @@ What does Reticulum Offer?
* Fully self-configuring multi-hop routing * Fully self-configuring multi-hop routing
* Asymmetric RSA encryption and signatures as basis for all communication * Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication
* Perfect Forward Secrecy on links with ephemereal Elliptic Curve Diffie-Hellman keys (on Curve25519) * Forward Secrecy with ephemereal Elliptic Curve Diffie-Hellman keys on Curve25519
* Reticulum uses the Fernet specification for encryption on links and to group destinations * Reticulum uses the `Fernet <https://github.com/fernet/spec/blob/master/Spec.md>`_ specification for encryption
* AES-128 in CBC mode with PKCS7 padding * AES-128 in CBC mode with PKCS7 padding
@ -37,6 +37,8 @@ What does Reticulum Offer?
* IVs are generated through os.urandom() * IVs are generated through os.urandom()
* Keys are ephemeral and derived from an ECDH key exchange on Curve25519
* Unforgeable packet delivery confirmations * Unforgeable packet delivery confirmations
* A variety of supported interface types * A variety of supported interface types

3
docs/manual/gettingstartedfast.html
View File

@ -43,7 +43,6 @@
<div class="section" id="getting-started-fast"> <div class="section" id="getting-started-fast">
<h1>Getting Started Fast<a class="headerlink" href="#getting-started-fast" title="Permalink to this headline"></a></h1> <h1>Getting Started Fast<a class="headerlink" href="#getting-started-fast" title="Permalink to this headline"></a></h1>
<p>What do we want to do? Something! When do we want to do it? Right now! Let’s go.</p>
<p>The best way to get started with the Reticulum Network Stack depends on what <p>The best way to get started with the Reticulum Network Stack depends on what
you want to do. This guide will outline sensible starting paths for different you want to do. This guide will outline sensible starting paths for different
scenarios.</p> scenarios.</p>
@ -60,7 +59,7 @@ in the development for the messaging and information-sharing protocol
<div class="section" id="develop-a-program-with-reticulum"> <div class="section" id="develop-a-program-with-reticulum">
<h2>Develop a Program with Reticulum<a class="headerlink" href="#develop-a-program-with-reticulum" title="Permalink to this headline"></a></h2> <h2>Develop a Program with Reticulum<a class="headerlink" href="#develop-a-program-with-reticulum" title="Permalink to this headline"></a></h2>
<p>If you want to develop programs that use Reticulum, the easiest way to get <p>If you want to develop programs that use Reticulum, the easiest way to get
started is to install Reticulum via pip:</p> started is to install the latest release of Reticulum via pip:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">pip3</span> <span class="n">install</span> <span class="n">rns</span> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">pip3</span> <span class="n">install</span> <span class="n">rns</span>
</pre></div> </pre></div>
</div> </div>

2
docs/manual/searchindex.js
View File

File diff suppressed because one or more lines are too long

61
docs/manual/understanding.html
View File

@ -333,10 +333,38 @@ destination, and <em>resources</em> that help make reliable data transfer more e
<p>In networks with changing topology and trustless connectivity, nodes need a way to establish <p>In networks with changing topology and trustless connectivity, nodes need a way to establish
<em>verified connectivity</em> with each other. Since the network is assumed to be trustless, Reticulum <em>verified connectivity</em> with each other. Since the network is assumed to be trustless, Reticulum
must provide a way to guarantee that the peer you are communicating with is actually who you must provide a way to guarantee that the peer you are communicating with is actually who you
expect. To do this, the following process is employed:</p> expect. Reticulum offers two ways to do this.</p>
<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>
<ul> <ul>
<li><div class="line-block"> <li><div class="line-block">
<div class="line">First, the node that wishes to establish connectivity will send out a special packet, that <div class="line">A packet is always created with an associated destination and some payload data. When the packet is sent to a <em>single</em> destination type, Reticulum will automatically create an ephemeral encryption key, perform an ECDH key exchange with the destinations public key, and encrypt the information.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">It is important to note that this key exchange does not require any network traffic. The sender already knows the public key of the destination from an earlier received <em>announce</em>, and can thus perform the ECDH key exchange locally.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">The public key part of the newly generated ephemeral key is included with the encrypted token, and sent along with the encrypted payload data in the packet.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the packet.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">A new ephemeral key is used for every packet sent in this way, and forward secrecy is guaranteed on a per packet level.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">In case the packet is addressed to a <em>group</em> destination type, the packet will be encrypted with the pre-shared AES-128 key associated with the destination. In case the packet is addressed to a <em>plain</em> destination type, the payload data will not be encrypted. Neither of these two destination types offer forward secrecy. In general, it is recommended to always use the <em>single</em> destination type, unless it is strictly necessary to use one of the others.</div>
</div>
</li>
</ul>
<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>
<ul>
<li><div class="line-block">
<div class="line">First, the node that wishes to establish a link will send out a special packet, that
traverses the network and locates the desired destination. Along the way, the nodes that traverses the network and locates the desired destination. Along the way, the nodes that
forward the packet will take note of this <em>link request</em>.</div> forward the packet will take note of this <em>link request</em>.</div>
</div> </div>
@ -368,18 +396,18 @@ recipient.</div>
</div> </div>
</li> </li>
</ul> </ul>
<p>In a moment, we will discuss the specifics of how this methodology is implemented, but let’s first <p>In a moment, we will discuss the details of how this methodology is implemented, but let’s first
recap what purposes this serves. We first ensure that the node answering our request is actually the recap what purposes this methodology serves. We first ensure that the node answering our request
one we want to communicate with, and not a malicious actor pretending to be so. At the same time is actually the one we want to communicate with, and not a malicious actor pretending to be so.
we establish an efficient encrypted channel. The setup of this is relatively cheap in terms of At the same time we establish an efficient encrypted channel. The setup of this is relatively cheap in
bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will also terms of bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will
rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is also rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is
more suitable to the application. The amount of bandwidth used on keeping a link open is practically more suitable to the application. The amount of bandwidth used on keeping a link open is practically
negligible. The procedure also inserts the <em>link id</em> , a hash calculated from the link request packet, negligible. The procedure also inserts the <em>link id</em> , a hash calculated from the link request packet,
into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each
other simply by referring to this <em>link id</em>.</p> other simply by referring to this <em>link id</em>.</p>
<div class="section" id="step-1-pathfinding"> <div class="section" id="pathfinding-in-detail">
<h4>Step 1: Pathfinding<a class="headerlink" href="#step-1-pathfinding" title="Permalink to this headline"></a></h4> <h4>Pathfinding in Detail<a class="headerlink" href="#pathfinding-in-detail" title="Permalink to this headline"></a></h4>
<p>The pathfinding method builds on the <em>announce</em> functionality discussed earlier. When an announce <p>The pathfinding method builds on the <em>announce</em> functionality discussed earlier. When an announce
is sent out by a node, it will be forwarded by any node receiving it, but according to some specific is sent out by a node, it will be forwarded by any node receiving it, but according to some specific
rules:</p> rules:</p>
@ -440,8 +468,8 @@ distance of <em>Lavg =</em> 15 kilometers, an announce will be able to propagate
kilometers in 34 minutes, and a <em>maximum announce radius</em> of 270 kilometers in approximately 3 kilometers in 34 minutes, and a <em>maximum announce radius</em> of 270 kilometers in approximately 3
days.</p> days.</p>
</div> </div>
<div class="section" id="step-2-link-establishment"> <div class="section" id="link-establishment-in-detail">
<h4>Step 2: Link Establishment<a class="headerlink" href="#step-2-link-establishment" title="Permalink to this headline"></a></h4> <h4>Link Establishment in Detail<a class="headerlink" href="#link-establishment-in-detail" title="Permalink to this headline"></a></h4>
<p>After seeing how the conditions for finding a path through the network are created, we will now <p>After seeing how the conditions for finding a path through the network are created, we will now
explore how two nodes can establish reliable communications over multiple hops. The <em>link</em> in explore how two nodes can establish reliable communications over multiple hops. The <em>link</em> in
Reticulum terminology should not be viewed as a direct node-to-node link on the physical layer, but Reticulum terminology should not be viewed as a direct node-to-node link on the physical layer, but
@ -511,6 +539,10 @@ reveal any identifying information about itself. The link initiator remains comp
<p>When using <em>links</em>, Reticulum will automatically verify all data sent over the link, and can also <p>When using <em>links</em>, Reticulum will automatically verify all data sent over the link, and can also
automate retransmissions if <em>Resources</em> are used.</p> automate retransmissions if <em>Resources</em> are used.</p>
</div> </div>
<div class="section" id="proven-delivery">
<h4>Proven Delivery<a class="headerlink" href="#proven-delivery" title="Permalink to this headline"></a></h4>
<p>TODO: Write</p>
</div>
</div> </div>
<div class="section" id="resources"> <div class="section" id="resources">
<span id="understanding-resources"></span><h3>Resources<a class="headerlink" href="#resources" title="Permalink to this headline"></a></h3> <span id="understanding-resources"></span><h3>Resources<a class="headerlink" href="#resources" title="Permalink to this headline"></a></h3>
@ -741,8 +773,9 @@ proof 11
</li> </li>
<li><a class="reference internal" href="#reticulum-transport">Reticulum Transport</a><ul> <li><a class="reference internal" href="#reticulum-transport">Reticulum Transport</a><ul>
<li><a class="reference internal" href="#reaching-the-destination">Reaching the Destination</a><ul> <li><a class="reference internal" href="#reaching-the-destination">Reaching the Destination</a><ul>
<li><a class="reference internal" href="#step-1-pathfinding">Step 1: Pathfinding</a></li> <li><a class="reference internal" href="#pathfinding-in-detail">Pathfinding in Detail</a></li>
<li><a class="reference internal" href="#step-2-link-establishment">Step 2: Link Establishment</a></li> <li><a class="reference internal" href="#link-establishment-in-detail">Link Establishment in Detail</a></li>
<li><a class="reference internal" href="#proven-delivery">Proven Delivery</a></li>
</ul> </ul>
</li> </li>
<li><a class="reference internal" href="#resources">Resources</a></li> <li><a class="reference internal" href="#resources">Resources</a></li>

7
docs/manual/whatis.html
View File

@ -59,13 +59,14 @@
<ul class="simple"> <ul class="simple">
<li><p>Coordination-less globally unique adressing and identification</p></li> <li><p>Coordination-less globally unique adressing and identification</p></li>
<li><p>Fully self-configuring multi-hop routing</p></li> <li><p>Fully self-configuring multi-hop routing</p></li>
<li><p>Asymmetric RSA encryption and signatures as basis for all communication</p></li> <li><p>Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication</p></li>
<li><p>Perfect Forward Secrecy on links with ephemereal Elliptic Curve Diffie-Hellman keys (on Curve25519)</p></li> <li><p>Forward Secrecy with ephemereal Elliptic Curve Diffie-Hellman keys on Curve25519</p></li>
<li><p>Reticulum uses the Fernet specification for encryption on links and to group destinations</p> <li><p>Reticulum uses the <a class="reference external" href="https://github.com/fernet/spec/blob/master/Spec.md">Fernet</a> specification for encryption</p>
<ul> <ul>
<li><p>AES-128 in CBC mode with PKCS7 padding</p></li> <li><p>AES-128 in CBC mode with PKCS7 padding</p></li>
<li><p>HMAC using SHA256 for authentication</p></li> <li><p>HMAC using SHA256 for authentication</p></li>
<li><p>IVs are generated through os.urandom()</p></li> <li><p>IVs are generated through os.urandom()</p></li>
<li><p>Keys are ephemeral and derived from an ECDH key exchange on Curve25519</p></li>
</ul> </ul>
</li> </li>
<li><p>Unforgeable packet delivery confirmations</p></li> <li><p>Unforgeable packet delivery confirmations</p></li>

3
docs/source/gettingstartedfast.rst
View File

@ -1,7 +1,6 @@
******************** ********************
Getting Started Fast Getting Started Fast
******************** ********************
What do we want to do? Something! When do we want to do it? Right now! Let's go.
The best way to get started with the Reticulum Network Stack depends on what The best way to get started with the Reticulum Network Stack depends on what
you want to do. This guide will outline sensible starting paths for different you want to do. This guide will outline sensible starting paths for different
@ -23,7 +22,7 @@ in the development for the messaging and information-sharing protocol
Develop a Program with Reticulum Develop a Program with Reticulum
=========================================== ===========================================
If you want to develop programs that use Reticulum, the easiest way to get If you want to develop programs that use Reticulum, the easiest way to get
started is to install Reticulum via pip: started is to install the latest release of Reticulum via pip:
.. code:: .. code::

45
docs/source/understanding.rst
View File

@ -308,10 +308,26 @@ Reaching the Destination
In networks with changing topology and trustless connectivity, nodes need a way to establish In networks with changing topology and trustless connectivity, nodes need a way to establish
*verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum *verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum
must provide a way to guarantee that the peer you are communicating with is actually who you must provide a way to guarantee that the peer you are communicating with is actually who you
expect. To do this, the following process is employed: expect. Reticulum offers two ways to do this.
For exchanges of small amounts of information, Reticulum offers the *Packet* API, which works exactly like you would expect - on a per packet level. The following process is employed when sending a packet:
* | A packet is always created with an associated destination and some payload data. When the packet is sent to a *single* destination type, Reticulum will automatically create an ephemeral encryption key, perform an ECDH key exchange with the destinations public key, and encrypt the information.
* | It is important to note that this key exchange does not require any network traffic. The sender already knows the public key of the destination from an earlier received *announce*, and can thus perform the ECDH key exchange locally.
* | The public key part of the newly generated ephemeral key is included with the encrypted token, and sent along with the encrypted payload data in the packet.
* | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the packet.
* | A new ephemeral key is used for every packet sent in this way, and forward secrecy is guaranteed on a per packet level.
* | In case the packet is addressed to a *group* destination type, the packet will be encrypted with the pre-shared AES-128 key associated with the destination. In case the packet is addressed to a *plain* destination type, the payload data will not be encrypted. Neither of these two destination types offer forward secrecy. In general, it is recommended to always use the *single* destination type, unless it is strictly necessary to use one of the others.
* | First, the node that wishes to establish connectivity will send out a special packet, that For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the *Link* API. To establish a *link*, the following process is employed:
* | First, the node that wishes to establish a link will send out a special packet, that
traverses the network and locates the desired destination. Along the way, the nodes that traverses the network and locates the desired destination. Along the way, the nodes that
forward the packet will take note of this *link request*. forward the packet will take note of this *link request*.
@ -333,19 +349,19 @@ expect. To do this, the following process is employed:
sending node can obtain verified confirmation that the information reached the intended sending node can obtain verified confirmation that the information reached the intended
recipient. recipient.
In a moment, we will discuss the specifics of how this methodology is implemented, but let’s first In a moment, we will discuss the details of how this methodology is implemented, but let’s first
recap what purposes this serves. We first ensure that the node answering our request is actually the recap what purposes this methodology serves. We first ensure that the node answering our request
one we want to communicate with, and not a malicious actor pretending to be so. At the same time is actually the one we want to communicate with, and not a malicious actor pretending to be so.
we establish an efficient encrypted channel. The setup of this is relatively cheap in terms of At the same time we establish an efficient encrypted channel. The setup of this is relatively cheap in
bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will also terms of bandwidth, so it can be used just for a short exchange, and then recreated as needed, which will
rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is also rotate encryption keys, but the link can also be kept alive for longer periods of time, if this is
more suitable to the application. The amount of bandwidth used on keeping a link open is practically more suitable to the application. The amount of bandwidth used on keeping a link open is practically
negligible. The procedure also inserts the *link id* , a hash calculated from the link request packet, negligible. The procedure also inserts the *link id* , a hash calculated from the link request packet,
into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each into the memory of forwarding nodes, which means that the communicating nodes can thereafter reach each
other simply by referring to this *link id*. other simply by referring to this *link id*.
Step 1: Pathfinding Pathfinding in Detail
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
The pathfinding method builds on the *announce* functionality discussed earlier. When an announce The pathfinding method builds on the *announce* functionality discussed earlier. When an announce
is sent out by a node, it will be forwarded by any node receiving it, but according to some specific is sent out by a node, it will be forwarded by any node receiving it, but according to some specific
@ -392,8 +408,8 @@ distance of *Lavg =* 15 kilometers, an announce will be able to propagate outwar
kilometers in 34 minutes, and a *maximum announce radius* of 270 kilometers in approximately 3 kilometers in 34 minutes, and a *maximum announce radius* of 270 kilometers in approximately 3
days. days.
Step 2: Link Establishment Link Establishment in Detail
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After seeing how the conditions for finding a path through the network are created, we will now After seeing how the conditions for finding a path through the network are created, we will now
explore how two nodes can establish reliable communications over multiple hops. The *link* in explore how two nodes can establish reliable communications over multiple hops. The *link* in
@ -450,6 +466,11 @@ reveal any identifying information about itself. The link initiator remains comp
When using *links*, Reticulum will automatically verify all data sent over the link, and can also When using *links*, Reticulum will automatically verify all data sent over the link, and can also
automate retransmissions if *Resources* are used. automate retransmissions if *Resources* are used.
Proven Delivery
^^^^^^^^^^^^^^^
TODO: Write
.. _understanding-resources: .. _understanding-resources:
Resources Resources

8
docs/source/whatis.rst
View File

@ -25,11 +25,11 @@ What does Reticulum Offer?
* Fully self-configuring multi-hop routing * Fully self-configuring multi-hop routing
* Asymmetric RSA encryption and signatures as basis for all communication * Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication
* Perfect Forward Secrecy on links with ephemereal Elliptic Curve Diffie-Hellman keys (on Curve25519) * Forward Secrecy with ephemereal Elliptic Curve Diffie-Hellman keys on Curve25519
* Reticulum uses the Fernet specification for encryption on links and to group destinations * Reticulum uses the `Fernet <https://github.com/fernet/spec/blob/master/Spec.md>`_ specification for encryption
* AES-128 in CBC mode with PKCS7 padding * AES-128 in CBC mode with PKCS7 padding
@ -37,6 +37,8 @@ What does Reticulum Offer?
* IVs are generated through os.urandom() * IVs are generated through os.urandom()
* Keys are ephemeral and derived from an ECDH key exchange on Curve25519
* Unforgeable packet delivery confirmations * Unforgeable packet delivery confirmations
* A variety of supported interface types * A variety of supported interface types