Replies: 5 comments 7 replies
-
|
I am not a lawyer, however in the United States, encryption is only allowed for command and control of amateur radio satellites. Is there a use case for that using Reticulum? Sure. But as it sits now, traffic using Reticulum to send and receive terrestrial data over US amateur radio would be prohibited, at least with my understanding of the Rules. Without getting into the politics of it all, I can foresee a future time where the encryption ban in the US is lifted. The wording in the manual still is applicable for other countries, though. For example in Poland, it is perfectly fine to encrypt communications over amateur radio. I would suggest that the line in the manual should be updated to include the words "where allowed" or "where encryption on amateur radio is legal" to prevent confusion. EDIT: I believe the spirit of the manual is that it's up to the end user to be sure that what they are doing is legal where they live, and not rely on whether or not the manual of a program is giving them permission to do something that could be illegal. As an aside, encryption is fine on public service and commercial frequencies in the US, assuming you hold the proper license. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply, what do you mean by public service frequency? |
Beta Was this translation helpful? Give feedback.
-
Fire, police, ambulance, road works, town/city/state government, schools... Things not public service: CB, GMRS, FRS... |
Beta Was this translation helpful? Give feedback.
-
|
What @kc1awv says here is completely spot on:
A just marginally thorough coverage of what you can and cannot do when and where, when it comes to RF emissions would take up more pages than the manual itself, and varies wildly from area to area. Other countries that do not prohibit encryption on amateur radio spectrum include Germany and Denmark. Also, many commercial or personal spectrum license holders use amateur radio digital modes on commercially or personally licensed spectrum, since it is often the most efficient way to establish communication. I am also not a lawyer, so take the following with a grain of salt, and as an interesting side-note. The following is my personal interpretation of the legal texts, and as such, just an opening for discussion on an interesting subject. In general, all countries within the EU legislative framework and the United States follow the ITU Radio Regulations, which sets forth some guidelines for the actual legal implementation in each separate legislation. This is reflected for example in the United States by the FCC Title 47 CFR Part 97, which contains the actual rules governing the amateur radio service in the US. Specifically, Part 97.113 defines the "Prohibited Transmissions" for the amateur radio service. The exact section of concern reads as follows:
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, and it would not be possible to verify any sort of connectivity or data delivery to destinations. As such, Reticulum first and foremost employs encryption because it is the most efficient way to make a decentralised 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. A bunch of grumpy OMs who detest digital modes and anything more new-fangled than CW might get annoyed and confrontational though, and I frankly don't know what is worse, the FCC or the OM Police Department. 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:
I can also foresee a future where the legislation is changed, but it will not happen without it being challenged by users who want the change. 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 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. Also, I will just move this to the discussion board. |
Beta Was this translation helpful? Give feedback.
-
|
Still not a lawyer. The issue gets even muddier when Amateur and ISM bands overlap, for instance.
Likely a holdover from Counterespionage in the Cold War. Encryption obscures the meaning, but so do ciphers, numbers stations, etc. By casting a wider net, they make prosecution easier. Like getting Al Capone for tax evasion. |
Beta Was this translation helpful? Give feedback.
-
|
I also take the position of permitting encryption on amateur radio bands (only concern is the airwaves are used for amateur purposes), however, I doubt we'll see these changes anytime soon. That being said, if my understanding is correct, if encryption is disabled, verification would not be possible. Let's assume that the user understood those risks and opted to send a message forgoing encryption anyway. Would it be possible to have an option within Reticulum, perhaps on an interface by interface basis to permit encryption? The interface would have an option called encryption_permitted and the default would be true. Ideally, reticulum would check the path to the destination before sending the message and if multiple paths are available, always default to the path with encryption, despite the user opting to forgo encryption in this case. The default configuration would be to require encryption for both outbound and inbound messages and along the route. My understanding of Reticulum is rudimentary at best, so please forgive me if this isn't possible. This project is extremely interesting, but I doubt that I'll be able to recruit any other hams out of fear for running afoul of the law, at least in the United States. |
Beta Was this translation helpful? Give feedback.
-
|
I believe it's still possible to use RNodes to send LoRa packets in the clear. It's not Reticulum and contains none of its benefits, but it's a good way to get hardware acceptance and get more supporters for changing encryption laws. That being said, while I've sent what I believe are raw packets, my SDR is currently missing, so I can't sniff the air directly. |
Beta Was this translation helpful? Give feedback.
-
|
I should clarify, I am a big proponent of using encryption for just about everything, however, my willingness to be made an example of by the FCC.... is less than lacking and my wallet even less so. That being said, I completely understand your stance on this issue. @faragher You have my attention. I'd be interested in your findings. |
Beta Was this translation helpful? Give feedback.
-
|
@iqw1345 I don't know if I still have the base code I was using, but I'll let you know if I find it. From what I remember I pulled in the rnode.py from the firmware repo, initiated the radio manually, then built packet objects to transmit directly. |
Beta Was this translation helpful? Give feedback.
-
|
@iqw1345 I needed two new SDRs for a P25 Phase 2 system, so I should be able to sniff out the raw packets and see if it's in the clear. I know any other LoRa module can pick it up, so I think that's "plaintext" enough in this context. |
Beta Was this translation helpful? Give feedback.
-
|
@iqw1345 Again, not a lawyer, however I can say with certainty that you can absolutely decode LoRa transmissions with either specialized hardware or even generalized SDRs. It's a bit painful to do with cheap SDR equipment, but it's absolutely doable. Here's a quick writeup I did: https://github.com/faragher/LoRa-Clear-Broadcast/blob/main/README.md If you decide to verify my findings, be advised that there's a single line in the ChirpChat manual that mentions it only works reliably with a SF of 12. I believe it's a hardware and processing issue, as SF doesn't magically hide data. |
Beta Was this translation helpful? Give feedback.
-
In the manual, it lists
amateur radio digital modesas a medium that reticulum can use. However, I'm fairly sure most countries (definitely the US and UK) ban the use of encryption on amateur bands. Is there some edge case in the law I'm not aware of? Did it mean to use amateur equipment in ISM bands (I don't know if that's legal either)? Is there something else I'm missing?Beta Was this translation helpful? Give feedback.
All reactions