Publishing Private Keys for Ham Radio Use

[iqw1345]

Moderator edit from the future (by @markqvist): There's some very important clarification regarding the questions asked in this post in this reply and this reply. Publishing an identity file will not make previously intercepted communication decryptable.

Since our previous discussion about legality of Reticulum on Ham Radio for US use, I have been thinking about an alternative, significantly more reasonable solution.

In the case for nomadnet, what if I just publicize my identity file? In theory, my communications should be public. It's not ideal, but my communications would be able to be decoded and I have no problem running that over the air. I experimented with this by copying the exact same identity file to two different computers. I was able to decode which ever computer sent the most recent announce. I haven't done much research, but I assume the different IP addresses between the two computers is a contributing factor.

This is just a thought, but perhaps having nomadnet have some sort of monitor mode? Where if fed some other identity file that is also publicized, it could decrypt the communications or perhaps a tool that is specifically designed to decrypt communications on the fly?

I could be entirely off the mark on this, but nevertheless, any feedback is appreciated.

[faragher]

Well, with the obvious statement of "by publishing your private key anyone can broadcast as you" out of the way, I wonder about the utility. It is technically possible to publish your public key and encrypt with your private, meaning anyone could decode your message but nobody could send a message as you, but that would require some modification to how the system works. It's also of little benefit over simply signing an unencrypted message (ignoring the fact that Reticulum needs encryption to function).

As you noted, it would also entirely break routing, as only the last announced machine would receive messages, but you're discussing for radio broadcast.

I think the sharing of an identity breaking routing makes Reticulum rather useless, but it might not be; I don't know all your potential use cases. The signing of an unencrypted message isn't supported, but there may be a way around that, acknowledging that breaking one link of encryption breaks them all. I'd have to think this through, and I'm only about 60% sure it's doable, but you could have shared private identities that were used only on radio endpoints, so the endpoints could decrypt and reencrypt on your behalf, which isn't terribly clean.

But you could also share an identity (with all the insecurity that brings, I won't mention it again) and make a custom communication application. Allow me to explain.

When you make a destination, there's an app name and aspects. So lxmf.delivery handles LXMF messages but, and this doesn't exist, lxmf.notdelivery can be for anything else. Announces, telemetry, recipes for pie, anything. And, best of my knowledge, the paths are stored per aspect.

So, entirely unintended behavior, you can try something like this. Make an app called, say, clear_broadcast. Now, you can set up aspects so you have a single identity across every single instance, but clear_broadcast.Steve would have different routing than clear_broadcast.George. However, you'd have some rather complicated routing decisions to make in the program because you're filtering out absolutely everything except those specific aspects you're listening for. So if you're listening for Steve and George, Ron can't be heard at all.

It's a generally bad idea, and expressly advised against in the manual (4.3.1) but it would allow known stations to broadcast in the clear to each other, assuming they were all expecting each other. It should be explicitly noted that you cannot use wildcards in this case, since aspects are used to generate a unique destination hash and the individual aspect data is lost.

The best I can think of is a little more complicated, and you'll lose some strength, but if you have a single Ham node you can connect to, you could write a program that sends the data to that radio, broadcasts destination and content in the clear using non-Reticulum encoding, then reassembles at all receiving stations. If those stations know the path, they re-encode and send it along. If they don't, they discard them. You may want to look into interface modes in that case, as there's no real reason to send announces over the air, just set things up either for local Reticulum delivery or for broadcast, which can be sent to the radio via Reticulum as normal.

Probably unclear and rambly, but that's my best idea. Specifically mark a message for broadcast and send it to the transmitting radio with instructions as to who's to receive it once it lands at the destination.

[iqw1345]

Thank you for getting back to me on this. I really appreciate it.

I broke the routing on a local level, but it didn't even occur to me that it could completely break routing on an even grander level. To that point, I certainly agree, breaking routing would render Reticulum completely useless.

Ideally, for radio usage only, my conversations could be viewed, but the routing should be signed. But like you said, this would offer little benefit over simply signing an unencrypted message.

The only way I can picture that is having a separate key all together specifically for routing, but I'm no cryptologist and I'm definitely not sure that would even work.

On a different note, this is how I was picturing this whole thing would work and what would be my use case:

Remote Location --- (Radio Connection) --- My computer --- (Local Network) --- Smart Phone
|
|
Nosy Ham

(Nosy Ham should be underneath Radio Connection)

Any communication to the Remote Location would have to be able to be deciphered because it crossed over a radio in a way that wouldn't compromise routing. It absolutely shouldn't be trusted as a result.

In the case above, if I were to send a message from the Remote Location to the Smart Phone, it'd have to be decipherable. I'd have to make the Smart Phone user aware that this link can be compromised. Anyone that I communicate with from the Remote Location would have to be informed that the link can be and should be assumed that it is compromised.

In my imagination, at least in the case for radio, the only reason there would be shared private identities is someone is trying to monitor another ham. But, if it's possible at all to do this without sharing private identities, I'd be 100% on board with that.

As for the custom communication, it's definitely something that can be done, and actually seems similar to JS8Call, especially about the parts about using other stations as a relay to reach another station. I'll look further into that as well.

I'm no programmer, but I think I understood a little bit of what you're saying. Nevertheless, I appreciate all of your help and hearing me out.

[faragher]

I'm happy to help. It's easy to say "you shouldn't do that," and I did, but it's good to mention why and if there are better ways. This is an important use case, and it's good to think about these things now.

Given that you're not a programmer, I'll avoid implementation specifics. I'm not familiar enough with amateur radio to speak that language, though (the handbook's right there, but there are only so many hours in the day!)

Having a single, symmetric key is called pre-shared key, or PSK, and it works how most WiFi routers do. Put in a password, you're on the network. Security is up to the individual computers. An asymmetric key is usually described as a lock and key, but in reality the lock can also open the key. It's used mostly to sign requests or begin a transfer because it's relatively slow. Since the public key doesn't need to be secure, it allows any user to say "Hey, here's a secure message only one person on the planet can read: here's a symmetric key!" which can be used from there on out and, almost as importantly, changed between communications.

The other direction, signing with the private key and saying "Hey, you all know my public key, but I'm the only person in the world who can sign this" is more what you're looking for.

So let's not re-invent the wheel, and see if we can get this set up while staying within both Reticulum and amateur radio standards.

I have done basically no research on JS8Call, but let's suppose that's already happening. You send a message from one station to another in the clear. Add a Reticulum destination hash and a signature. You now have a non-encrypted point to point (or multicast, I guess) message with the minimum to confirm the source and know the destination.

Each radio endpoint would then need to be able to encode and decode the message. Since we're not sharing identities in this design, that means they'd need to connect to their own network as usual. Easy enough. The key is the sender would be the recipient of the Reticulum message and decode it and the receiver would then encode it again to send to the final destination. Basically, Reticulum wouldn't know about the radio in general, but then you lose some routing capability.

The simplest way I can see it is to make a bridge and a dedicated program. Like with Echobot receiving a message and sending it back, you could send a message to a receiver that would then broadcast the data over the radio. You'd need to store public keys that were either transferred out of band or requested from known nodes, and there's a bit more work to route at the end, but it's very doable.

Actually, this may be best case. Instead of broadcasting a Reticulum address you could send your station ID as a header. Example, for user WABC123 station 003: WABC123.003-<ReticulumDestination>#This is my plain text message#<MessageSignature>-WABC123.003

So the receiving destinations can do whatever repeating/routing is appropriate over amateur radio, and when it's received the radio can reconstruct the message, using its own encryption, and send it to the destination. Since it only comes through that program, it can add "This message has gone through insecure channels" to the final message at all times, saving over the air bandwidth.

There are some other little things Reticulum can do, but generally speaking, I think this works the best. Worst case you can even drop the message signature and then there's no need to synchronize public keys.

Is this something that you think would work well for your application? I think this needs some specifics and graphics to make it understandable, but I'd like to make sure it's something you (as a representative of the amateur radio community, no pressure :D ) would find useful before I sit down with a pen and paper.

[iqw1345]

After reading your entire message, I must say, your solution to this is simply exquisite. It makes my original solution look like complete, utter garbage. (Because it was). Again, I can't believe I didn't see the obvious solution here. A plaintext bridge type solution makes perfect sense.

Thank you for the refresher on symmetric and asymmetric keys. It's been a while since I played with them. I do have experience playing around with PGP, but it's been awhile.

So, I'll give you a little knowledge on JS8 as well. JS8 allows communication over the radio, but it's really slow. Normally, it sends about ~16 WPM. Generally speaking, the slower you go, the further out you can get. When you first turn it on, you send out a "heartbeat" and this tells everyone that your station is alive and monitoring that frequency. It's just a brief packet that contains your call sign. When the heartbeat packet is received by other stations, that station automatically transmits back to you. Knowing this, you can send messages to other stations or you can create a daisy chain by relaying messages from station to station until it reaches its destination. Unfortunately, sometimes, you receive part of the transmission and you either have to ask for a re-transmission or fill in the words yourself. Either way, there's no guarantee that everything was received correctly. On a sidenote, I could spoof my call sign and no one would be any the wiser.

Taking your best case example, this actually makes a ton of sense. I'll brush it up a little bit to make it ham radio like for the example.

It looks like Reticulum uses announces as JS8Call uses heartbeats. Perhaps, it would look like this for announcements:

K1ABC-0 <ReticulumSource><MessageSignature>

Sending:

K1ABC-0 To K1ABC-1 <ReticulumDestination>#PlainTextMessage#<MessageSignature>

And I'd imagine it would respond like this or in a way that's more efficient on bandwidth:

K1ABC-1 To K1ABC-0 <ReticulumDestination>#ACK#<MessageSignature><MaybeReceivedMessageHash>

I added the K1ABC-0 To K1ABC-1 to show a specific destination that involves a ham station. And the MaybeReceivedMessageHash to show which message was received and to guarantee receipt. Maybe there's a better way of doing it though.

In the event of no acknowledgement, it should re-transmit X amount of times until either an acknowledgement is received or the watchdog times it out.

As far I know, hashing and signatures are allowed. but in the case of hashing the Reticulum destination, I worry that it would be considered obscuring the destination, and thus not be permitted. Perhaps there's a legitimate need to hash the destination and I am just unfamiliar with it. Happy to hear your thoughts. Anything to keep me out of trouble :) I misread the documentation. All destinations in Reticulum are represented by hashes. As far as I am concerned, it's no different than a phone number or email address.

The only thing I can't think of is how it would handle multiple stations simultaneously without jamming each other, but I suppose that could be a work in progress. I have some ideas on that, but perhaps it's better to focus on getting it working first.

Brilliant idea to mark the message as insecure automatically because it becomes more trustless that way. I personally like the idea of signatures as it guarantees some integrity, which is something I haven't really seen done on the radio yet. The option to verify these signatures off the air can be done, like how Signal allows you to verify users by scanning a QR code.

All in all, I think this would work beautifully. If you need additional specifics and graphics, please feel free to let me know. I'd be happy to cobble something together. As a representative of the amateur radio community, I really look forward to the day that you become a ham. I think you'd enjoy it. :)

Happy to hear your thoughts on all of this. Thanks again.

[faragher]

I am extremely happy to help, this kind of overcoming limitations and designing systems is one of my great joys.

So, I'll give you a little knowledge on JS8 as well. JS8 allows communication over the radio, but it's really slow. Normally, it sends about ~16 WPM. Generally speaking, the slower you go, the further out you can get. When you first turn it on, you send out a "heartbeat" and this tells everyone that your station is alive and monitoring that frequency. It's just a brief packet that contains your call sign. When the heartbeat packet is received by other stations, that station automatically transmits back to you. Knowing this, you can send messages to other stations or you can create a daisy chain by relaying messages from station to station until it reaches its destination. Unfortunately, sometimes, you receive part of the transmission and you either have to ask for a re-transmission or fill in the words yourself. Either way, there's no guarantee that everything was received correctly. On a sidenote, I could spoof my call sign and no one would be any the wiser.

Thanks for the run-down. The heartbeat seems very similar to the concept of the announce, just with the announce containing the public key. Being on the same conceptual page will likely help interoperability. Since each Reticulum node only knows the next hop in the path, the heartbeat may make for some interesting integration.

Amateur radio is based on trust and respect anyway. If someone's willing to spoof, they're willing to run unlicensed or jam, and there's only so much someone can do.

Retransmissions are a good point. More on that below.

And I'd imagine it would respond like this or in a way that's more efficient on bandwidth:

K1ABC-1 To K1ABC-0 <ReticulumDestination>#ACK#<MessageSignature><MaybeReceivedMessageHash>

Some of that is implicit. If K1ABC successfully verifies the signature, the message is accurate. Otherwise any number of things can go wrong. It's worth adding a message designation, but that could be embedded in the message, so it would also be part of the check. So something like:

K1ABC-1 to K1ABC-0 #ACK# K1ABC-1-<00-FF>

would acknowledge that particular message, although there's no promise that message is received properly, but I'd call it low-risk. Since, in theory, a single sender would only use one transmitter, and less than 255 messages should be pending at any point, I'd call it sufficient. There are likely better ways, but this is simple and human-parsable.

The reason I removed the destination is, by default, Reticulum doesn't have acknowledgements or a sender address. LXMF does, and you can enable "proofs," but it can't be assumed you have a sender address unless you're using something that contains that data by default, like LXMF, as an intermediary.

This shouldn't be a problem, please see below.

As far I know, hashing and signatures are allowed. but in the case of hashing the Reticulum destination, I worry that it would be considered obscuring the destination, and thus not be permitted. Perhaps there's a legitimate need to hash the destination and I am just unfamiliar with it. Happy to hear your thoughts. Anything to keep me out of trouble :) I misread the documentation. All destinations in Reticulum are represented by hashes. As far as I am concerned, it's no different than a phone number or email address.

That's a good analogy. To expand, you as a person have an identity. You have a phone number and a radio callsign, and both are uniquely linked to you. A destination hash differs only in that we can take an identity, an app and some aspects, and generate the same destination every single time. As an analogy, if I had your name, I could look up your phone number or radio callsign without much issue, whereas if I only had your phone number, at least before the Internet, I'd have to do much more work.

So I'd call it just as personally identifiable.

That being said, and please correct me if I'm wrong, my understanding is your callsign can only be used under your direct control and you are responsible for the content of their messages. Since you're effectively vouching for every Reticulum user on the network, I would assume broadcasting your station ID fulfils the requirements for identification.

The only thing I can't think of is how it would handle multiple stations simultaneously without jamming each other, but I suppose that could be a work in progress. I have some ideas on that, but perhaps it's better to focus on getting it working first.

That's the rub. I see one of two currently implemented options. LoRa systems use a well-published standard and each spreading factor is orthogonal to the others (so they claim) so if you used, say SF 7 - 11, you could have 5 parallel data streams overlapping on a certain bandwidth. This does require more than a little additional work, as you'd need to specify what SF you were using prior to transmission, reconfigure both radios, and then send the data. You'd likely need a control channel to coordinate, which also runs into multiple-access issues, but nothing unsolvable.

The other system is a trunked system like Project 25 Phase 2. It's widely used, it's mature, and it broadcasts in the clear unless otherwise configured. Effectively you have a control channel that negotiates/assigns a channel, then the actual message is broadcast on that frequency. It does require a rather large bandwidth on your receiver, and if the band is too wide you may need multiple receivers, but it does allow parallel data streams which can all be monitored at once by the receiver, making blind transmissions easier. It may, however, require an authoritative system for assigning channels unless you simply set up "Channel 1 is busy, trying channel 2, ... Channel MAX is busy, waiting for an open channel." I have a Project 25 Phase 2 scanner using RTL-SDRs (I need two for this region, most you only need one) that works beautifully.

Depending on bandwidth use and allocations, the situation changes. If you have 125kHz available (+/- 25% I think is the stated maximum for the SX series chips in use) then you can stack 5 LoRa signals on top of each other, maybe 10 if you drop to 62.5 kHz mode, but need to use one, or a separate system, for coordination.

Ah, I should've read the requirements on JS8Call before I bothered with this section. Seeing as how the requirements are 25-160Hz per channel, you can have approximately a thousand channels in the space of 5 - 10 LoRa channels. Yeah. I suggest trunked data. Mark has implemented a Carrier Sense Multiple Access scheme (CSMA) for RNode and I suggest using that as a starting point for any automated trunking. As much as I like CDMA and other spread-spectrum multiple access systems, there's little reason for such rugged systems in this case.

I don't know what your systems look like, but my SDRs handle up to two megahertz in bandwidth, making watching the entire space trivial. You can also use pseudorandom numbers to change the order in which the channels are checked every time, reducing the over-use of low channel numbers. Or the reverse if you have channels you prefer!

This is all pretty broad knowledge for me, and anyone with knowledge of trunking systems may either decide this is a great idea, or will point and laugh at me. All I ask is they correct me. :D

Brilliant idea to mark the message as insecure automatically because it becomes more trustless that way. I personally like the idea of signatures as it guarantees some integrity, which is something I haven't really seen done on the radio yet. The option to verify these signatures off the air can be done, like how Signal allows you to verify users by scanning a QR code.

Just because it's not "secure" doesn't mean it can't be verified. It would be great to have trusted messages over the radio. You wouldn't want to send your banking info in the clear, but if you RSVP for a party, they'll at least know it was from you.

All in all, I think this would work beautifully. If you need additional specifics and graphics, please feel free to let me know. I'd be happy to cobble something together. As a representative of the amateur radio community, I really look forward to the day that you become a ham. I think you'd enjoy it. :)

Part of me is sad my grandfather's radios went to someone else, but it was to my Godfather and I wasn't into radio at the time. Plus that was before they removed the Morse requirements, and that was a little more investment than I was willing to make at the time. I have plenty of receivers, and even a (questionable) Gonset Communicator 3, so really it's just a matter of putting in the work and trying to fix what the previous owner did to that Communicator (they hacked off the entire power supply connector system and soldered a lamp cord to the 120v input, ignoring the entire power conditioning system).

Very happy to learn while doing like this, though.

[markqvist]

Ok, I need to add some very important points here.

what if I just publicize my identity file? In theory, my communications should be public. It's not ideal, but my communications would be able to be decoded

No. Even if you publish your identity file (and you should never, ever do this), communication you initiate would not be decryptable. Remote systems will use the public part of your identity in the link establishment process to verify the encrypted link setup, when creating links to you, but the actual encryption keys are ephemeral on a per-link basis.

All of your outgoing traffic would still be completely and totally encrypted, and if you somehow disabled that in your end, packets would never reach the recipient programs/applications.

Publishing your private keys (identity file) would only mean that anyone would be able to route traffic intended to you to a location of their choosing instead, and be able to intercept links intended for you.

They would need to actively do this though, and for each and every link, and then forward the traffic to you as a MiTM attack, to be able to successfully decrypt traffic to you. If the link request actually reaches you first, the link is still secure, since keys are completely new and random for each link established.

Likewise, previously recorded traffic from a link going to you will not be decryptable by obtaining your identity file at some point in the future. This is what is called "forward secrecy", and it would be pretty shoddy if we didn't have this.

I have said it before, and I will happily say it again. There is no way to "turn off" encryption in Reticulum. I specifically, and painstakingly, designed it as such. One of the points being to make sure that an idea like this wouldn't be carried out into reality. If you can compromise link integrity in one place, you can compromise it everywhere.

As a more constructive approach, I strongly suggest putting effort into changing the antiquated and stagnant stance against encryption within the US ham radio community instead. Reticulum is a fantastic technology for amateur radio, that can help tremendously in making amateur radio digital modes more relevant again. Revolutionary work was done in the 80's and 90's within digital amateur radio, and we still have benefits from that today, but without a more modern approach, which is impossible without encryption, the field will remain irrelevant outside of pure hobby/sports use.

And I say this as an amateur radio operator myself, with a great deal of love and respect for the field, but with also a realistic and somewhat sombre outlook on its future.

[faragher]

As a more constructive approach, I strongly suggest putting effort into changing the antiquated and stagnant stance against encryption within the US ham radio community instead. Reticulum is a fantastic technology for amateur radio, that can help tremendously in making amateur radio digital modes more relevant again. Revolutionary work was done in the 80's and 90's within digital amateur radio, and we still have benefits from that today, but without a more modern approach, which is impossible without encryption, the field will remain irrelevant outside of pure hobby/sports use.

While I generally agree, this is a large undertaking that's far easier said than done, particularly with the reactionary "we can't trust anyone with anything" stance amongst too much of the public and legislative body.

Fundamentally we'd have to show people that it was in their enlightened self-interest to change the laws. Since amateur radio is supposed to be for public communication and encryption is, basically by definition, private and point to point, people would have to be shown why that's important and how they can benefit.

Sadly, since few people would benefit, because they don't care about communication, privacy, or security more than public social media, images stored on someone else's computer, and streaming video, there wouldn't be much support. That lack of support means a lack of a voting bloc which means no political support.

There needs to be a way to sell the concept to enough of the public to make it a popular issue. On the one hand, places like China and Russia having free communication is an easy sell to the American public, but it's easy to see how that could quickly become unpopular, seeing as how the EU is currently trying to get backdoors into social media. I shouldn't and won't speak too much more on political issues, even in the broadest terms.

By way of example, I have mentioned a local dam which has been issue number one for a local alderman. For less than a million dollars we can dredge the area behind the dam which is currently barely deep enough for canoes and has gone from a reservoir to a burgeoning marsh. The last "emergency maintenance" was performed 20 years after it was ordered. If it fails, it is estimated to kill a dozen people and damage or destroy much of downtown. Nobody cares.

I am all for sitting down and having a discussion about how changing the law could be achieved, but it's one of those jobs that requires a political action group and actual multinational campaigns to make it seem like the US is behind the curve and all of those wonderful communications are out of our reach.

Again, I am more than happy to consult and teach people all the tricks I've picked up and point them to the industry standards for persuasion and information campaigns, but I don't have the passion to carry the banner here or even make sound arguments. I've just become too practical to try to change public policy.

[iqw1345]

Mark,

First off, I want to make it clear that I respect this project immensely.

Secondly, I should have stated this in my original post as I am sure it's every developer's nightmare to read the words, "publishing my private keys." I recognize completely and wholly that it's completely idiotic to leak my private keys onto the internet. I recognize that I essentially compromised myself in every meaning of the word possible, from MITM to routing.

I want you to know that I 100% agree with your stance on encryption and I respect your decision on it.

I have said it before, and I will happily say it again. There is no way to "turn off" encryption in Reticulum. I specifically, and painstakingly, designed it as such. One of the points being to make sure that an idea like this wouldn't be carried out into reality. If you can compromise link integrity in one place, you can compromise it everywhere.

I know in the past I have asked you about the possibility of not mandating encryption for the sake of ham radio. Yes, it was an absolute long shot and seeing how this project proclaims it is a cryptography-based networking stack, it was a dumb request and if I were in your shoes, I'd shoot it down too. However, I still want to find away to use this project on the ham bands that doesn't end up with me behind bars. You can see how that would lead me to try another method like publishing my private keys in a way that wouldn't require sacrificing the encryption aspect for everyone else. Although, I will admit that I did forget about ephemeral keys.

Likewise, previously recorded traffic from a link going to you will not be decryptable by obtaining your identity file at some point in the future. This is what is called "forward secrecy", and it would be pretty shoddy if we didn't have this.

I am aware of the forward secrecy. Honestly, my train of thought was that I don't care if previously recorded traffic was decryptable. As long as it was decryptable from the present onwards.

As a more constructive approach, I strongly suggest putting effort into changing the antiquated and stagnant stance against encryption within the US ham radio community instead. Reticulum is a fantastic technology for amateur radio, that can help tremendously in making amateur radio digital modes more relevant again. Revolutionary work was done in the 80's and 90's within digital amateur radio, and we still have benefits from that today, but without a more modern approach, which is impossible without encryption, the field will remain irrelevant outside of pure hobby/sports use.

Outside of Reticulum, I absolutely disagree with you. Simply put, the winds are blowing in our direction, at least in the United States. The FCC just voted to eliminate the 300 baud limitation on the HF bands in favor of a 2.8 kHz bandwidth limitation. As digital modes improve, these modes will more efficiently use that 2.8 kHz. Meaning, we can expect significantly faster digital modes in the future. I can reasonably bet that encryption is coming.

Politically, I can certainly put more effort into changing the "antiquated and stagnant stance against encryption within the US ham radio community", but I have very little faith in that. It's going to be the developers writing the software that are going to be leading this push as they are the ones with sway. As an example, VARA HF has included an AES 256 encryption option, granted it's only for non-hams only, but nonetheless, a step in the right direction. But, as I said previously, we just need to be patient on this matter.

However, I would like to see this project on the forefront of when encryption is permitted because if a version of reticulum existed without encryption right now, there's a real opportunity here to establish a significant presence on the ham bands. It's plain as day that this project would serve as an alternative to Winlink (E-mail) and VARA Chat (Chatting Client with other Ham Operators) combined. This project can reach users outside of the ham bands as a chatting client. If it could find a way to take advantage of weak signal modes as well, such as FT8 and JS8, I think you'd have an absolute show stopper. When encryption eventually does become permitted, you've got the jump on it.

That being said, by no means am I asking you to compromise Reticulum in its current state in any way. Ideally, there would be a way to bridge the non-encrypted and encrypted worlds together without having any compromises. Heck, I'd settle with a fork that could be used on radio, but I realize that would effectively double your workload.

However, if nothing like this is feasible, I'll stop bothering you on this topic. Nonetheless, I appreciate all the work done on this project.

[faragher]

I mean, putting direct Reticulum communication over amateur radio bands is currently impossible (and the encryption requirement won't change) but can I suggest that the answer, if there is one, is both?

Using the system we've been hashing out, Reticulum can be part of a larger solution. A sub-optimal use for it, but it can be something that gets into the mind-space of amateur radio users. And they get more and more used to packet data over the air, like JS8 (watched one of the presentations on it, it's rather neat and would fit with Reticulum so well!) and get used to seeing Reticulum on either end, as well as running over unlicensed bands (can we run Reticulum over JS8 connections on 915 MHz or other unlicensed bands, understanding that our range will be far, far lower than, say, 6 meter?) then people will start to say, "Why can't we just bridge this gap? All the extra steps are really problematic," then the answer is "there's this one part of the law . . ." Some people will want to change Reticulum to have no encryption. That can't happen, so some will try to recreate it, see the phenomenal amount of work involved, and give up. The rest may just say "Well, then let's have our club try to change that antiquated law!"

At least that's my pie in the sky assessment of a path forward.

[kc1awv]

I usually don't do this, but I'm gonna throw my two cents in here. (Oh, who am I kidding, I love throwing my two cents in)

putting direct Reticulum communication over amateur radio bands is currently impossible

That's misleading. It's totally possible, and I can show it to you! Whether or not it's permissible is the $64k question. Nothing in Part 97 of the FCC rules state that encryption is not allowed. It's the intent to obscure the meaning that is not permitted. Though, one could argue both sides here - I don't think encryption in Reticulum is intended to obscure anything, it's the intent of the user that's the deciding factor.

I can provide a real world anecdote here. Take ARES for example. Locally, there's a nuclear power plant that the ARES group participates in drills with. Part of these drills are to relay information from the 'command center' to the local EOCs to provide logistics and situational awareness to the people on the ground. One of these information sheets is a status update from the plant, that notifies the reader of the ongoing situation at the plant that is considered critical information. This information details a lot of things, from status of the plant, to the weather, to evacuation statuses, where to go and what to send... etc.

Part of the actual training is to send this information (it's a form that's filled in by the receiving station) and use specific code words for filling in that information. It is trained, without any modicum of uncertainty, that by using these code words and specific form layouts, the 'general public and news media' should have a difficult time taking the information from the air and creating their own news reports or relaying that information from/to 'someone else that is not an official' - which means, the specific intent is to obscure the meaning of the message over the air. No encryption is taking place, but I will argue to my dying breath that this is exactly against the FCC rules.

[faragher]

While technically true that there is no prohibition on encryption by name, there's no lawyer that couldn't convince a jury that encryption is different from procedure words.

It's everyone's own decision, but I cannot provide legal advice, cannot advocate what (in my amateur opinion) seems against said regulations, and would simply advise that doing this and getting caught will likely end with a forfeited license and a very long court battle at the individual's expense. It might not even force the court to hear the case in general.

But I appreciate all viewpoints weighing in on the matter, so long as individual users realize it's a risk. It would be far better to get permission than forgiveness, since one person getting forgiveness may deny permission to everyone else for an indeterminant time.

[iqw1345]

I appreciate all the responses. Thanks again, everyone!

[atomicthumbs]

As a more constructive approach, I strongly suggest putting effort into changing the antiquated and stagnant stance against encryption within the US ham radio community instead.

From what I've seen, I get the sense that this is in direct conflict with the broad sense that one of amateur radio's best characteristics is that it's "self-policing." Even SCS released PACMON so people could decode the communications using their proprietary OFDM protocols, so that people can see what others are communicating about. Any significant effort toward this in a way that would allow Reticulum to function would likely see massive opposition at every level, from individual operators to the ARRL and FCC, all the way up to the fact that the United States is a signatory to ITU treaties that forbid the use of encryption on amateur radio. You can predict the reasoning: if you can't decode someone's communications, they could be using the amateur radio service for criminal activities, or business, or other forbidden things, and you'd have no way to tell and snitch on them to the FCC.

There is an ITU amendment stating that it doesn't forbid encryption in communications between amateurs in a specific jurisdiction, but it is still a hard uphill fight domestically. The only people I've seen pushing for revision of regulations in that sense are the HSMM people, and as far as I know that's generally abandoned in favor of a technique of publishing keys.

Reticulum is an incredible piece of software, and its capabilities are ideal for implementing something wonderful: a nationwide-or-wider, disaster-proof, amateur store and forward HF data radio network, a spiritual successor to the packet radio BBSs of old. However, the only ways I can see of actually achieving this dream are:

• fork Reticulum and gut it like a fish, either: replacing everything encrypted about it with techniques that use signing instead of encryption, or requiring that all originating and destination nodes upload their communications to a trusted public repository via another channel, or requiring that all nodes disclose any previous communication when requested by another
• design something with similar operating characteristics that's otherwise fundamentally unlike Reticulum.

it'd be nice if there was another way, but to maintain the philosophical principles of Reticulum, it would have to be an incompatible network.

Edit: thinking further about it, the "disclose all communications when requested" solution could sit on top of Reticulum. Just have mail software that will divulge a list of previously sent messages upon request, and their contents upon request, and tie it to a public repository of public keys tied to callsigns. Make it refuse to send mail to a destination that's not a registered amateur public key. Repo updates could be distributed through the network. You could also design it to double-send all messages: once to the recipient, with a copy sent to a central authority that'd handle message requests, or publish them online.

That would comply with the "obscure meaning" part of the regulation without compromising the security of Reticulum. People running routing nodes wouldn't be responsible for the forwarded messages any more than someone running a packet node would be responsible if some jackass with no callsign sent messages through it, or a repeater operator would be responsible for a crank using their repeater. If someone runs noncompliant software, they'd be breaking the regulations, but that's on them, not on Reticulum. (Ideally, to keep everyone else happy, you'd also have to make sure that the amateur Reticulum network is airgapped, somehow, to prevent/discourage it from routing non-amateur traffic; is this is possible using IFACs?)

[markqvist]

I know your argument is coming from the perspective of illuminating how tedious a process cultural and legal change would be, and I can certainly appreciate it in that regard. I still completely maintain that it's the only constructive approach in the long run, at least in the context of Reticulum. What anyone else does outside of that, I am in no control of.

Some of the below will be rather direct, and is of course not aimed at you personally. I very much appreciate you bringing up the topic, and voicing your thoughts.

From what I've seen, I get the sense that this is in direct conflict with the broad sense that one of amateur radio's best characteristics is that it's "self-policing."

I'd argue that is primarily a myth. Self-policing is entirely possible even though communications content is not directly readable. For Reticulum, just don't enable IFAC on your interfaces, and headers (destination hash, hops and type flags) are still in the clear, which will let anyone with medium access read packet destinations. Combined with already implemented callsign beaconing mechanisms, that is all you need to effectively self-police.

See some operator continuously messaging destinations that belong to commercial entities, or someone transporting traffic to such entities? You can do all the policing you need.

All other users than amateur radio operators, who don't have any legal requirements to beacon their callsign, can still have perfect anonymity if they want.

It's the best of both worlds, and was specifically designed like that.

There is an ITU amendment stating that it doesn't forbid encryption in communications between amateurs in a specific jurisdiction

Exactly right. It's unfortunate that the issue is rather devoid of clarity in the US, unlike some other jurisdictions.

Reticulum is an incredible piece of software, and its capabilities are ideal for implementing something wonderful: a nationwide-or-wider, disaster-proof, amateur store and forward HF data radio network, a spiritual successor to the packet radio BBSs of old.

I appreciate you seeing this, because all of what you mention here (and more, of course) were exactly the kinds of things I wanted to make possible with Reticulum, and now that it is technically possible, people are already building it.

In the present time though, all of those things are also completely useless in the real world without the guarantees of immutability of traffic, security, verifiability and confidentiality that Reticulum provides.

So why can Reticulum provide all of these capabilities within such a small overhead envelope that it can run over HF packet? Because the entire system was designed to let the information theoretical consequences of various cryptographic techniques and primitives work in favor of the intended design goals. When it comes to efficiency, it turns out that entropy is not always your enemy.

Fork Reticulum and gut it like a fish [...] replacing everything encrypted about it with techniques that use signing instead of encryption

From the very beginning of sketching the Reticulum protocol, I was very well aware that at some point, this idea would come up, and that the above "solution" would seem like the most "sensible" quick-hack for people who just wanted Reticulum without encryption. Luckily, it is simply not possible to do it.

Reticulum makes many implicit assumptions about the level and homogeneity of entropy in the raw data flows. Breaking any of those will make things fall apart very quickly, and I can assure you that trying to remove encryption is the best way to break all of those assumptions.

You will then end up with a protocol that works most of the time at first, then very little at all, then maybe a bit again, and everyone involved in that project will spend a lot of time pulling their hair, in a wild goose-chase of "bugs" that aren't really such.

Yes, I did this completely on purpose, and not only did I take very great care to make it practically impossible to scissor out the encryption from Reticulum, I tried my best to make it as confusing and painful as possible for anyone who would try to do so.

Which leads us nicely to your other proposal:

design something with similar operating characteristics that's otherwise fundamentally unlike Reticulum

Certainly an option. Good luck.

it'd be nice if there was another way

There is: Just use Reticulum.

If you really have to do it over amateur radio spectrum in the US, my suggestion would be to take every care you can to align that use to the actual context and intended regulatory envelope of the relevant legislation, so that if anyone does come knocking, you can not only show them exactly what is going on, but also impress them with what you are doing, and how it perfectly resonates with the spirit of amateur radio.

For everyone else in the world, that needs Reticulum for a surprisingly wide variety of purposes, it would be complete and utter madness to even tip-toe an ångström towards provisions for disabled or even degraded encryption.

Naturally, it will not happen.

Thanks for bringing it up :)

[iqw1345]

I initially started this conversation thinking that encryption was going to be the sole issue on getting this working on the ham bands and that it either had to be forked and gutted or something else had to be used. I've said it before and I'll say it again, I do feel bad asking for a way around encryption because I really do support encryption. After reading these posts, I am starting to realize that I was wrong because removing encryption isn't the only solution.

In regards to @atomicthumbs edit, if that were possible, and I won't claim to have any knowledge on that, I would feel significantly more comfortable using that. It would be easier to argue that my communications are not encoded to obscure the meaning, but to preserve the integrity. And, here is X website that reveals my communications.

For Reticulum, just don't enable IFAC on your interfaces, and headers (destination hash, hops and type flags) are still in the clear, which will let anyone with medium access read packet destinations.

I need to re-read the manual because I missed this part. Either way, I think it makes it more compelling that communications are encoded to preserve integrity because the headers could be encrypted, but are not.

I have played around with Direwolf and Reticulum, and it looks good. The only thing that I would hypothetically add to that is some identification of what is being transmitted, so people at least know what they are looking at. Like Reticulum at the beginning of the packet, for example.

An additional thought, what if it were possible to disclose your communications over Reticulum to a specific node? And that node would disclose anything sent to it on a website. Just thinking out loud here.

[faragher]

It might be simpler to look at it from another direction: Reticulum cannot route without being encrypted. If you wish to broadcast unencrypted (as an example, no statement on if that is or is not the best solution) why not set up a protocol that gets messages from a Reticulum interface, decodes it (by virtue of being the Destination, and therefore having only the keys for things sent to it) and broadcasts it? The message itself could have sender and recipient and the receiving station could check if it had the route known, then pack the message up as a Reticulum message and send it along.

I don't think it's a great idea, as far as the goals of Reticulum, but using Reticulum to transfer messages that can be broadcast via, say, JS8, and then repackaged on the far end is a better solution than trying to get a round peg in a square hole and wondering if we can still make it roll.

[markqvist]

The only thing that I would hypothetically add to that is some identification of what is being transmitted, so people at least know what they are looking at. Like Reticulum at the beginning of the packet, for example.

You can use the already built-in beacon functionality. It would have to be a matter of convention being established here, but something like "R/MY4CLL" would probably work out just fine to signify that this was Reticulum traffic over amateur.

An additional thought, what if it were possible to disclose your communications over Reticulum to a specific node? And that node would disclose anything sent to it on a website. Just thinking out loud here.

Or, just keep it in your own log of contacts as hams have always done. If the need arises, you can present it. It's super easy (practically automatic) with current Reticulum-based software to do so, as long as you don't delete your messages. For other stuff, such as shell sessions to check up on your remote repeater site, just write down your session start and end times in your logbook, and that's it.

Thinking further about it, the "disclose all communications when requested" solution could sit on top of Reticulum. Just have mail software that will divulge a list of previously sent messages upon request, and their contents upon request.

I think that is completely over the top, entirely draconian and perfectly unnecessary. As I mentioned above, just keeping a QSO log like normal would fall right in line with the original intentions and scope of the regulations.

It really doesn't have to be more complicated than that.

[markqvist]

Unfortunately, I will have to lock this discussion now, since the position of the Reticulum project has been already made very clear, and the discussion keeps circling back to various ideas around breaking core guarantees of security and privacy in favor of neutering Reticulum to fit into a legal context that is directly opposed to the core goals of the project.

I don't have the time to answer every permutation of "what if we just add an option that says DisableEncryption".

In this post, and several other like it before, I have already made it very clear why this will never happen, why it is technically impossible to do within Reticulum, and why it would be catastrophic for normal users if such an option existed.

Any further discussions on this idea, that does not reflect an understanding of the above, and/or is not completely thought through by its author will be locked with a reference to this post, or simply deleted.

[markqvist]

@iqw1345, I deleted your last question, for the above reasons. I copied the text for it though, so it doesn't just disappear into the void. If you want it for your own reference, archive or posting elsewhere, message me on LXMF or Matrix, and I will send it to you.