Updated docs and manual

This commit is contained in:
Mark Qvist 2022-09-30 11:15:34 +02:00
parent 3f2075da6f
commit 7940ac0812
7 changed files with 38 additions and 31 deletions

View File

@ -34,10 +34,14 @@ class Packet:
``RNS.Destination.GROUP`` destination or a :ref:`RNS.Link<api-link>`. ``RNS.Destination.GROUP`` destination or a :ref:`RNS.Link<api-link>`.
For ``RNS.Destination.GROUP`` destinations, Reticulum will use the For ``RNS.Destination.GROUP`` destinations, Reticulum will use the
pre-shared key configured for the destination. pre-shared key configured for the destination. All packets to group
destinations are encrypted with the same AES-128 key.
For ``RNS.Destination.SINGLE`` destinations and :ref:`RNS.Link<api-link>` For ``RNS.Destination.SINGLE`` destinations, Reticulum will use a newly
destinations, reticulum will use ephemeral keys, and offers **Forward Secrecy**. derived ephemeral AES-128 key for every packet.
For :ref:`RNS.Link<api-link>` destinations, Reticulum will use per-link
ephemeral keys, and offers **Forward Secrecy**.
:param destination: A :ref:`RNS.Destination<api-destination>` instance to which the packet will be sent. :param destination: A :ref:`RNS.Destination<api-destination>` instance to which the packet will be sent.
:param data: The data payload to be included in the packet as *bytes*. :param data: The data payload to be included in the packet as *bytes*.

Binary file not shown.

View File

@ -131,12 +131,13 @@ bits, ensuring the Reticulum address space could potentially support galactic-sc
This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should
be sufficient, even far into the future. be sufficient, even far into the future.
By default Reticulum encrypts all data using elliptic curve cryptography. Any packet sent to a By default Reticulum encrypts all data using elliptic curve cryptography and AES. Any packet sent to a
destination is encrypted with a derived ephemeral key. Reticulum can also set up an encrypted destination is encrypted with a per-packet derived key. Reticulum can also set up an encrypted
channel to a destination, called a *Link*. Both data sent over Links and single packets offer channel to a destination, called a *Link*. Both data sent over Links and single packets offer
*Forward Secrecy* and *Initiator Anonymity*, by using an Elliptic Curve Diffie Hellman key exchange *Initiator Anonymity*, and links additionally offer *Forward Secrecy* by using an Elliptic Curve
on Curve25519 to derive ephemeral keys. The multi-hop transport, coordination, verification Diffie Hellman key exchange on Curve25519 to derive per-link ephemeral keys. The multi-hop transport,
and reliability layers are fully autonomous and also based on elliptic curve cryptography. coordination, verification and reliability layers are fully autonomous and also based on elliptic
curve cryptography.
Reticulum also offers symmetric key encryption for group-oriented communications, as well as Reticulum also offers symmetric key encryption for group-oriented communications, as well as
unencrypted packets for local broadcast purposes. unencrypted packets for local broadcast purposes.
@ -442,8 +443,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
* | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the * | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the
packet. packet.
* | A new ephemeral key is used for every packet sent in this way, and forward secrecy is guaranteed on a * | A new ephemeral key is used for every packet sent in this way.
per packet level.
* | Once the packet has been received and decrypted by the addressed destination, that destination can opt * | Once the packet has been received and decrypted by the addressed destination, that destination can opt
to *prove* its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet, to *prove* its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet,
@ -453,7 +453,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
* | In case the packet is addressed to a *group* destination type, the packet will be encrypted with the * | 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* 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 destination type, the payload data will not be encrypted. Neither of these two destination types can offer
forward secrecy. In general, it is recommended to always use the *single* destination type, unless it is 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. strictly necessary to use one of the others.

View File

@ -685,9 +685,12 @@ over a Reticulum network. Packets to will automatically be encrypted if
they are adressed to a <code class="docutils literal notranslate"><span class="pre">RNS.Destination.SINGLE</span></code> destination, they are adressed to a <code class="docutils literal notranslate"><span class="pre">RNS.Destination.SINGLE</span></code> destination,
<code class="docutils literal notranslate"><span class="pre">RNS.Destination.GROUP</span></code> destination or a <a class="reference internal" href="#api-link"><span class="std std-ref">RNS.Link</span></a>.</p> <code class="docutils literal notranslate"><span class="pre">RNS.Destination.GROUP</span></code> destination or a <a class="reference internal" href="#api-link"><span class="std std-ref">RNS.Link</span></a>.</p>
<p>For <code class="docutils literal notranslate"><span class="pre">RNS.Destination.GROUP</span></code> destinations, Reticulum will use the <p>For <code class="docutils literal notranslate"><span class="pre">RNS.Destination.GROUP</span></code> destinations, Reticulum will use the
pre-shared key configured for the destination.</p> pre-shared key configured for the destination. All packets to group
<p>For <code class="docutils literal notranslate"><span class="pre">RNS.Destination.SINGLE</span></code> destinations and <a class="reference internal" href="#api-link"><span class="std std-ref">RNS.Link</span></a> destinations are encrypted with the same AES-128 key.</p>
destinations, reticulum will use ephemeral keys, and offers <strong>Forward Secrecy</strong>.</p> <p>For <code class="docutils literal notranslate"><span class="pre">RNS.Destination.SINGLE</span></code> destinations, Reticulum will use a newly
derived ephemeral AES-128 key for every packet.</p>
<p>For <a class="reference internal" href="#api-link"><span class="std std-ref">RNS.Link</span></a> destinations, Reticulum will use per-link
ephemeral keys, and offers <strong>Forward Secrecy</strong>.</p>
<dl class="field-list simple"> <dl class="field-list simple">
<dt class="field-odd">Parameters<span class="colon">:</span></dt> <dt class="field-odd">Parameters<span class="colon">:</span></dt>
<dd class="field-odd"><ul class="simple"> <dd class="field-odd"><ul class="simple">

File diff suppressed because one or more lines are too long

View File

@ -180,12 +180,13 @@ congestion, a one-line code change can upgrade the Reticulum address space all t
bits, ensuring the Reticulum address space could potentially support galactic-scale networks. bits, ensuring the Reticulum address space could potentially support galactic-scale networks.
This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should
be sufficient, even far into the future.</p> be sufficient, even far into the future.</p>
<p>By default Reticulum encrypts all data using elliptic curve cryptography. Any packet sent to a <p>By default Reticulum encrypts all data using elliptic curve cryptography and AES. Any packet sent to a
destination is encrypted with a derived ephemeral key. Reticulum can also set up an encrypted destination is encrypted with a per-packet derived key. Reticulum can also set up an encrypted
channel to a destination, called a <em>Link</em>. Both data sent over Links and single packets offer channel to a destination, called a <em>Link</em>. Both data sent over Links and single packets offer
<em>Forward Secrecy</em> and <em>Initiator Anonymity</em>, by using an Elliptic Curve Diffie Hellman key exchange <em>Initiator Anonymity</em>, and links additionally offer <em>Forward Secrecy</em> by using an Elliptic Curve
on Curve25519 to derive ephemeral keys. The multi-hop transport, coordination, verification Diffie Hellman key exchange on Curve25519 to derive per-link ephemeral keys. The multi-hop transport,
and reliability layers are fully autonomous and also based on elliptic curve cryptography.</p> coordination, verification and reliability layers are fully autonomous and also based on elliptic
curve cryptography.</p>
<p>Reticulum also offers symmetric key encryption for group-oriented communications, as well as <p>Reticulum also offers symmetric key encryption for group-oriented communications, as well as
unencrypted packets for local broadcast purposes.</p> unencrypted packets for local broadcast purposes.</p>
<p>Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports, <p>Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports,
@ -481,8 +482,7 @@ packet.</div>
</div> </div>
</li> </li>
<li><div class="line-block"> <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 <div class="line">A new ephemeral key is used for every packet sent in this way.</div>
per packet level.</div>
</div> </div>
</li> </li>
<li><div class="line-block"> <li><div class="line-block">
@ -496,7 +496,7 @@ public signing key.</div>
<li><div class="line-block"> <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 <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> 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 destination type, the payload data will not be encrypted. Neither of these two destination types can offer
forward secrecy. In general, it is recommended to always use the <em>single</em> destination type, unless it is 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> strictly necessary to use one of the others.</div>
</div> </div>

View File

@ -131,12 +131,13 @@ bits, ensuring the Reticulum address space could potentially support galactic-sc
This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should
be sufficient, even far into the future. be sufficient, even far into the future.
By default Reticulum encrypts all data using elliptic curve cryptography. Any packet sent to a By default Reticulum encrypts all data using elliptic curve cryptography and AES. Any packet sent to a
destination is encrypted with a derived ephemeral key. Reticulum can also set up an encrypted destination is encrypted with a per-packet derived key. Reticulum can also set up an encrypted
channel to a destination, called a *Link*. Both data sent over Links and single packets offer channel to a destination, called a *Link*. Both data sent over Links and single packets offer
*Forward Secrecy* and *Initiator Anonymity*, by using an Elliptic Curve Diffie Hellman key exchange *Initiator Anonymity*, and links additionally offer *Forward Secrecy* by using an Elliptic Curve
on Curve25519 to derive ephemeral keys. The multi-hop transport, coordination, verification Diffie Hellman key exchange on Curve25519 to derive per-link ephemeral keys. The multi-hop transport,
and reliability layers are fully autonomous and also based on elliptic curve cryptography. coordination, verification and reliability layers are fully autonomous and also based on elliptic
curve cryptography.
Reticulum also offers symmetric key encryption for group-oriented communications, as well as Reticulum also offers symmetric key encryption for group-oriented communications, as well as
unencrypted packets for local broadcast purposes. unencrypted packets for local broadcast purposes.
@ -442,8 +443,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
* | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the * | When the destination receives the packet, it can itself perform an ECDH key exchange and decrypt the
packet. packet.
* | A new ephemeral key is used for every packet sent in this way, and forward secrecy is guaranteed on a * | A new ephemeral key is used for every packet sent in this way.
per packet level.
* | Once the packet has been received and decrypted by the addressed destination, that destination can opt * | Once the packet has been received and decrypted by the addressed destination, that destination can opt
to *prove* its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet, to *prove* its receipt of the packet. It does this by calculating the SHA-256 hash of the received packet,
@ -453,7 +453,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
* | In case the packet is addressed to a *group* destination type, the packet will be encrypted with the * | 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* 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 destination type, the payload data will not be encrypted. Neither of these two destination types can offer
forward secrecy. In general, it is recommended to always use the *single* destination type, unless it is 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. strictly necessary to use one of the others.