Reticulum @ Mesh Jam 2022

[4c3e]

Hi all, as part of Mesh Jam 2022 in Philadelphia, I will be running a Reticulum workshop at 4:15pm EDT August 13th, hosted at Iffy Books! The event is totally free and will be live streamed and recorded for those that cannot make it in person. You can view the full Mesh Jam schedule here: https://iffybooks.net/event/mesh-jam-day-1/

Edit:
Full recording 👉 https://dai.ly/x8d2gco
Slides: https://reticulum.space/rns

[OtisByron]

That's exciting! I won't be able to make it in person unfortunately, but I'll definitely be watching the recording.

[markqvist]

This is great! Wish I could be there in person :) Really looking forward to watching the recording.

[4c3e]

We are live now, here is the link: https://iffybooks.club/MeshJam#config.startWithAudioMuted=true&config.startWithVideoMuted=true
(Please include the URL params so you join with mic and audio off 😄)

[4c3e]

Full recording posted here: https://dai.ly/x8d2gco
Will also make it accessible via bittorrent, ipfs, and i2psnark later today.

[4c3e]

Also will post it as a file on the RNS testnet when I get a chance 😄

[zenith777777]

Great work on your presentation!

[markqvist]

Thanks so recording and sharing the talk. It was a good presentation. Would you mind sharing a torrent or something else for a download of the recording? I would love to have a copy to put on my nomadnet node as well, if you don't mind. Thanks again!

[stevewa2066]

I think it was well done too! Mark, Could you go into a bit of the encryption and if it can be turned on or off ? I’m referring to the US’s issue with encrypted packets. Some have argued if the protocol is public it should satisfy the FCC. Steve NOFPF

On Wed, Aug 17, 2022 at 4:41 PM zenith777777 ***@***.***> wrote: Great work on your presentation! — Reply to this email directly, view it on GitHub <#84 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APRMG4UM3JHZQJNR4NWKAGTVZV2CBANCNFSM536B7ZDA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Pardon the brevity, sent from a mobile device. So there.

[markqvist]

Reply on this below :)

[markqvist]

Yes, I would love to expand a bit on that.

Before we dive into the grit and details, I want to make it clear that it is not possible to turn off encryption in Reticulum. This is by design, and will not change. If you read on, you will understand why this is, and learn how ensuring the encryption of all data is completely central for Reticulum to work at all.

Reticulum does have the unencrypted Plain destination type, but it cannot be routed over multiple hops, and is solely used for local broadcast and discovery purposes, mostly by the internals of the protocol itself. In general use, this destination type will and should never be necessary to use for normal applications.

First, let me say that there is no broad issues with encrypted data over various radio links in the US. Almost all commercial wireless systems use some form of encryption. Practically all commercial and business radio systems being installed today will be encrypted. Likewise, encryption is used on practically all wireless networking platforms, from WiFi to LTE (4G) and LoRaWAN.

The issue crops up when dealing with the amateur radio service in the US specifically. The legislation for amateur radio is laid out in the FCCs Part 97 rules.

Now, let me start by saying that I have experienced, that most people that argue against the use of cryptography in US amateur radio have not even read Part 97 in it's entirety, or even the parts relevant to encryption. As a result, there is a lot of misconceptions and strange ideas floating around out there.

Let me also say that I am not a lawyer, and have no legal training. I have spent a good deal of time helping a number of businesses and individuals to obtain RF spectrum licenses, and creating and implementing designs for a wide range of RF systems, which entails having to read and understand a lot of regulations, and a lot of conversation with the officials managing these regulations. This may lend a little bit of credibility to what I am postulating here. Still, anyone should make up their own mind on this before doing or implementing anything.

So let us go straight to where the proverbial dog is buried. Part 97.113 defines the "Prohibited Transmissions" for the amateur radio service, which is what we are after. Be mindful that this section is the only part of the entire Part 97 rules that could be construed to have any relevancy to encrypted communications. The exact section of concern reads as follows:

Music using a phone emission except as specifically provided elsewhere in this section; communications intended to facilitate a criminal act; messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.

Out of this section, it is obviously the "messages encoded for the purpose of obscuring their meaning" part that is relevant to this discussion. The point here is very clear. If you encode a message, in any way (encryption or not), for the purpose of obscuring its meaning, that will be a prohibited transmission. It is the purpose that is of importance here though. Encryption in and of itself is not illegal to use over amateur radio in the US, and in fact, Part 97 does not include the word "encryption" even once.

This means that there is plenty of situations where you can use systems that employ cryptography and encryption without breaking Part 97 rules.

Reticulum does not, per se, employ encryption to "obscure the meaning of messages". Reticulum fundamentally needs packets to be encrypted for the transport and routing layers to even work at all. If you could turn off the encryption and replace it with a dummy cipher, just inserting plaintexts, nothing would work. It would not be possible for the Transport layer to verify paths through the network, it would not be possible to sequence resource transfers, it would not be possible to verify any sort of connectivity or data delivery to destinations, and loop avoidance and replay-attack avoidance would fail.

As such, Reticulum first and foremost employs encryption because it is the most efficient way to make a decentralized routing and mesh protocol work at all, and frankly, it is the only way to do so. It is therefore solely the intention of the operator that bears relevance when using Reticulum over amateur radio spectrum, if you do not use Reticulum because you want to hide the content or meaning of messages, and nobody can legally prove otherwise, that part of the law cannot be used against you.

Even in the places where the above legal wording is implemented, there is plenty of situations where I would personally not have any qualms what so ever with using Reticulum, for example:

• Using nomadnet to access pages on an amateur radio node that is publicly accessible (there can be no intention of obscuring meaning, since the content being sent is accessible to all licensed amateurs).
• Using Reticulum to program a system for checking status of, and controlling a remote repeater site.
• Creating a home automation system allowing you to control stuff (again the purpose here is not to obscure the meaning, but to make sure others can not remotely turn on your furnace or unlock your gate)
• Sending messages to, and retrieving messages from a shared message board for amateurs.

I can foresee a future where the legislation is changed to actively encourage the use of cryptography, but it will not happen without it being pushed by users who want the change, or without the FCC perceiving a change in desired usage of the amateur spectrum.

I take the stance that cryptography and encryption is already perfectly fine on amateur radio spectrum in many cases, but not all, and that we should work towards a situation where the prohibition of encryption is not just omitted, but the use of cryptography is actively protected and encouraged. This is my own stance, and it is definitely an unpopular one in many circles within the amateur radio community, mostly because of the lack of understanding of what cryptography actually is, and the value it provides.

I have yet to hear a good argument in favor of the prohibition of encryption within the amateur radio service, and omitting the incredible value of cryptography and encryption from the amateur radio service is severely damaging its relevancy and usefulness in the world of the present day.