Updated docs and manual

RNS/Packet.py

@@ -34,10 +34,14 @@ class Packet:
     ``RNS.Destination.GROUP`` destination or a :ref:`RNS.Link<api-link>`.
 
     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 data: The data payload to be included in the packet as *bytes*.

docs/manual/_sources/understanding.rst.txt

@@ -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
 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
-*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
 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
     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
     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
     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
     strictly necessary to use one of the others.
 

docs/manual/reference.html

@@ -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,
 <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
-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">
 <dt class="field-odd">Parameters<span class="colon">:</span></dt>
 <dd class="field-odd"><ul class="simple">

docs/manual/understanding.html

@@ -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.
 This is obviously complete and ridiculous over-allocation, and as such, the current 128 bits should
 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
-<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
 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,
@@ -481,8 +482,7 @@ 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
+<div class="line">A new ephemeral key is used for every packet sent in this way.</div>
-per packet level.</div>
 </div>
 </li>
 <li><div class="line-block">
@@ -496,7 +496,7 @@ public signing key.</div>
 <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
+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
 strictly necessary to use one of the others.</div>
 </div>

docs/source/understanding.rst

@@ -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
 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
-*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
 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
     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
     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
     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
     strictly necessary to use one of the others.