Encryption / Secondary Channels

[Eagle]

Hi all,

since this is my first post here, I’d like to thank everyone involved in Meshtastic development. Thank you very much for this open source project.

I have been playing with Meshtastic for a week now, on TTGO Lora32 hardware, and mostly through the Android App (latest beta) and through the CLI (on linux box).

There is something that I would like to do but it seems that I can’t achieve it. I would like to communicate between my nodes with a custom encryption key, so that neither content or geolocalisation is disclosed to other nodes.

Ideally, I would follow the dev advice : keep the base channel (primary channel) with default settings so that the radio may be included in the mesh with unkown other users of the area. Fair enough. So I created a secondary channel. Since I could not get how to do so on the Android App, I created it through the CLI, using a random generated key on “Device A”, which worked.

I got the string representation of the key listed with “meshtastic --info”, let’s pretend it is “abcdef”.

Then I tried to transfer the key to “Device B” and “Device C” with the CLI but I failed. Apparently, doing :

meshtastic --ch-index --ch-set psk "abcdef"

will fail with error of type mismatch (expected a ‘byte array’ but got a ‘string’).

It there a way to replicate 1 secondary channel across devices with CLI ? I saw the “–seturl” command but the only URL I could find was from “–info” and is said to cover ALL channels. I would really want to cherry pick what key goes on what device, so this “URL of everything” is going to be an issue very soon for me.

I tried it anyway, and it worked, so I got two devices with the same channels config, “primary” and “secondary”. BTW I find this wording a bit confusing, IIUC the “primary” is the radio settings, while the “secondary” are encryption-defined talk groups.

Then I could send message through this custom-psk encrypted channel, using the CLI for the emitter, and receiving on the receiver with the android App. But I could not message on this channel directly from the Android App.

So I thought “Fair enough, the Android App can not handle secondary channels, fair enough, so I will just use a custom psk key for the primary, so that Android App send message with this key, and be patient about nice handling of channels from Android App”.

But then I stumbled into the same issue : how do I set a custom PSK key for the primary channel, and how should I replicate it from device to device using the CLI ?

Is there a solution at all, currently working, to exchange messages with a custom encryption key from the Android App ?

Thank you very much, cheers.

[garth]

The secondary channels are an experimental feature, you are a pioneer doing some of the first testing! The overwhelming majority of meshtastic use is the default config.

[Eagle]

Thank you Garth.

Developers, can I do something to help you improve this “secondary channel” feature and support ?
Is there an other feature on the way to provide this (very desirable) feature of “private talk groups” ?

For the record, in case someone stumble upon this thread, here is what I ended up doing : I set a random PSK key on the primary channel, then used the URL provided by “–info” to update the other nodes with the “–seturl” feature.

It works, but I can’t use default primary anymore, and this all-channels URL feature sounds a bit weird.

Regards,

[mc-hamster]

Figure out how to come up with more free time in the week

[garth]

The first thing is it needs some testing and bug fixes, statistically it is essentially unused right now.

Neither me or @AndreK can even start on adding it to the phone apps until the code is tested and works, there is documentation and examples and it has been integrated in a mostly transparent to the user way into the text message app packet type on the device. The overwhelming majority of users won’t use the feature and should not have to deal with it at all.

Some of this is code, but a lot of it is going to be coordination with the devs working on assorted clients. There are also a lot of messaging features that are coming first and I think many of the theoretical use cases for for multi channel are handled by features we have that are not implemented across clients like DM’s, replies, tapbacks etc.

[lester]

I very much disagree with the sentiment that most users shouldn’t or wouldn’t use secondary channels. People are primarily getting these for private backup coms. The reason no one is using secondary channels is because their useless in their current state. Nobody is communicating through nodes with their computer, they’re using their phones. Personally I think the way to simplify and improve the experience is to actually make the default “Primary” channel invisible. Most people would like to piggy back off other nodes while still maintaining their own private channel and not jumping through hoops in configuration menus or terminal commands to get it to work. Private secondary channels should be the focus, not the Primary channel (in my opinion). And then if someone wanted, they could gain access to the Primary channels settings if they so desired to change something or enable the “Public” chat through an advanced menu option. It really seems convoluted how it currently functions.

[mc-hamster]

The issue is right now, as you’re pointing out, client support for secondary channels is immature

We’re a group of volunteers working on this on our free time and would love contributions to help shore up this area. As an open source project, we have a guiding principal around here that volunteers / contributors do what they are personally passionate about. This is, of course, not our day job.

Let’s find or build some momentum or designs for this. What or how would the functionality tie into the user experience?

[lester]

Thank you for reminding me of the volunteer nature of this project. Sorry if my post came across as negative. I didn’t mean it to be. I am very impressed and thankful for how much progress this project has had and am amazed at the accessibility that these open source projects provide. You all are amazing! I might be able to make up some UI design ideas of how this feature could be implemented and post them for inspiration as something I can contribute.

[Eagle]

Hi @mc-hamster, thank you for caring.

First thing I would do is clean-up the vocabulary, and possibly the code-base, so that concerns are well defined and well separated.

Current “channel” definition includes both radio settings and channel settings. It would be an improvement, in my opinion, to separate both more clearly. Radio settings are only radio settings, and define basically how to send packets through the LoRa layer, and how to listen. Channels on the other hand is a property of the meshtastic protocol, one layer above (at least). If the word “channel” is too ambiguous, let’s use “private room”.
Also, I don’t think selecting the radio sub-band based on the name given to the “channel” is a great idea. This is a fairly basic setting that most users will understand.

I think it is fine to have a default channel (private room).

I also think it could be desirable to have “non private rooms”, IE rooms that you will receive and be able to decode if you listen on the right radio settings, but I will let others discuss this feature.

“Private rooms” should provide the following desirable features :

• groups privacy
• repeater selectivity (select what channels should be repeated, don’t repeat everything so that you save bandwidth if other groups are using same radio settings, and also prevent a easy DoS on the mesh network by a bad guy)
• users should have an easy way to share 1 “private room” (basically its key) with an other user, without having to share “all private rooms”. Currently, it seems that the way to share a secondary channel is to share all of them, which is a real defect in my opinion.

On the user interface design, there is plenty of inspiration to take from the myriad of group messaging apps, such as telegram etc. In my opinion, nothing fancy is required, basically 1 tab per “private room”, sorted by most recently used rooms, and this is perfect.

I would really, really love to see that implemented, and if I can help please let me know how.

Regards,

[mc-hamster]

Maybe we can do some ux rapid prototyping around this and then we can rally people on a call or or zoom or whatever … to shoot darts at the prototype, talk about what would work, what won’t work and then iterate on the prototype.

We have the backend done but no North Star to guide how the user interaction would work. Unlike many things here, this is something that will need to be closely coordinated between a lot of applications and having a clear North Star would help.

[lester]

@Eagle I agree about the channel naming confusion. I think the backend radio settings should definitely be kept separate. Also, thanks for pointing out that a DoS attacks could be very damaging to a public node network. I wonder if we could build in some kind of protection for this, but that’s for a different discussion. @mc-hamster, I think a call is an excellent idea, and would love to be involved if I may. I can build out some ideas of how the UX could work and maybe even throw together some app page designs for reference.

[mc-hamster]

The only “public” mesh network we have now is the one setup by the default device configuration and that’s only because the crypto keys for that are distributed with the firmware. Even with secondary channels, there really isn’t a concept of a public mesh.

If you’d like to collect the information, brainstorm and work on a rapid prototype, go ahead. I’d bet there are people here who would like to participate.

Once you’re ready for the firing squad, either you could setup a gathering or we can work on that together.

[Eagle]

Thank you all again for your fine work, greatly appreciated.
Let me know what if there is something I can do. I am also a developer, but not much experienced in android and embedded unfortunately (mostly a functional prog guy working on highly reliable network stuff). But if I can help, let me know how. Cheers

[garth]

Pretty much everything I said here remains true Encryption / Secondary Channels - #5 by garth

These secondary channel / group features have generated a ton of discussion, but little contributed code and I have never received any TestFlight feedback requesting secondary channel messaging. The code to get this started is going to be testing on device and figuring out how to work with the text message app port num. Most of us are not working in the language we do at work so don’t let that stop you

[lester]

@mc-hamster Sounds good. I’ll get started on some proposed ways of implementations and then I’ll initiate a meet-up by coming back to this discussion once I have something flushed out.

[lester]

@garth @mc-hamster @Eagle Got some mockups I’m ready to run through if you guys are open to a virtual meet-up. Want to get some feedback before I get too ahead of myself. Let me know how we should proceed.

[mc-hamster]

Post your mockups here. I need to schedule a developer check-in for progress on 1.3 and will send out a scheduler invite for that soon. Will add you to that agenda.

It’s likely going to be on a weekend based on prior availability.

Are you on our discord? It’ll be hosted as a video chat in there.

[lester]

Yes, I have discord.
Here are the mockups that I made from the ideas I had about implementing what we currently call “secondary channels”. Please feel free to pick them apart. I’m not a backend person, so my ideas may be way off base, but I hope I can contribute something.

The main ideas I’m going for are these:
-Easily use neighboring devices to communicate further without sharing info before-hand
-Primary channel is now just “Mesh”
-Secondary channels are just “Channels”
-The default “Mesh”(currently default Primary Channel) is referred to as a public mesh in the hopes of using it as such. In advanced settings you can add other Mesh Presets and assign them to devices if you do not want to contribute to or utilize the Public Mesh or want more security/less traffic.
-Sharing location to Mesh and “Mesh Chat” are disabled by default.
-The preferred mode of communication is through channels or direct to another person.
-Each device can have one admin channel which allows it to have settings and firmware changes over the air. (there’s something like this in the works right?)
-Channels and their keys are stored on the phone and not the Lora device, so you can change the Lora device to a new mesh and retain all your channels. Also possibly more secure if messages are not decrypted on meshtastic device? If a router is intercepted it doesn’t contain the keys. Is this how secondary channels already work?

Below are the mockups and one flow chart that I threw some ideas onto.

|

|

|

|

[lester]

|

|

|

|

[lester]

|