[Feature Request]: Deterministic Channel PSK from Channel Name Option

[Dokument]

Contact Details

[email protected]

Tell us your idea.

Description:
I would like to be able to use the Channel Name to consistently generate the same PSK for said channel. This option would be available when generating a new channel, and would not be selected by default. When enabling this option, the user should be informed that anyone else using the same channel name can read any messages in this channel.

Why would you want this feature?
This feature would allow for interest groups/rooms/topics for like minded meshtastic users. It would also make it very easy to get two people connected since they only need to exchange the channel name to get connected. This would be exceptionally useful for large gatherings, emergency response, etc.

Example uses:

• At a conference, everyone could use "room104" to talk about things going on in room 104.
• At an emergency response coordination site. "medical", "fire", "police" are quick ways to get everyone connected without all the noise of a default channel.
• Sports team names.
• "MyNodeName" or node id "!33699de0" could be used as a one-to-many broadcast for information from a specific node to many people.
• There are endless uses, but this is a powerful mechanism to have in place.

It is critically important that if this feature is implemented, that the same Channel Name ALWAYS generates the same PSK, on all devices (android/iphone/desktop/etc), otherwise the feature does not work. Therefore it may be necessary, now or later, to implement a versioning selection option.

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[caveman99]

That's what sharing by QR code is for. Guessing a channel PSK from its name (and documenting how its done is souncecode) would undermine encryption in meshtastic.

[b8b8]

All it would take to "hack" any and every channel would be to guess the channel name.....

[Dokument]

I understand it is similar to sharing a QR code, but it is different.

• Sharing QR codes is cumbersome on both sides, especially for new users. Overwriting channels, adding multiple of the same, making changes that you aren't quite sure about (as a new user), etc.
• I understand that there is a URL that can be shared as well, this has the same issues as above
• What if I want to share a Meshtastic channel over a DM using Meshtastic? I cannot send a QR code, Sharing the URL takes up almost the whole message, and is more data to send, and sharing the Channel key and name is again cumbersome. These would still be the only option for sharing channels not using the deterministic key option requested here.

Regarding the comment that it would "undermine encryption", this is not true. It is no different than how meshtastic works today with the default channel. Also, I would like to remind that there are many ways to use Meshtastic.

@thebentern

• Please see my comment above, this is no different than how the default channel works today. In my feature request, I did suggest that we communicate to the user how this feature would work, and it would not be enabled by default.

@b8b8

• This is not a hack, but is very much the exact feature that is desired out of this functionality. Just like how the default channel works today.

[b8b8]

By removing all randomness from the initial key generation you are inadvertently making the short channel name the "key", Which is very insecure and open to abuse.

Longfast is a preloaded special case and AQ== is not the full key.

Taken to the extreme, if the channel names could only be specified as a single digit number then they produce the same reproducible key, then there would only be 10 possible encryption keys to try before you are guaranteed to find the one being used. Your channel name input becomes the single unique portion of the key.

All the non-police (in your example) in the area could just type "Police" into their apps and then get access to the whole channel when they are in fact not police.

[Dokument]

@b8b8
There are no issues with all of the scenarios you have described. These channels would be created with the intention of being easily "joinable" by others.

"All the non-police (in your example) in the area could just type "Police" into their apps and then get access to the whole channel when they are in fact not police."

• That is correct and is the exact type of desirable use case that this feature would provide. This functionality does not exist today.

[garthvh]

• sharing

• What if I want to share a Meshtastic channel over a DM using Meshtastic? I cannot send a QR code, Sharing the URL takes up almost the whole message, and is more data to send, and sharing the Channel key and name is again cumbersome. These would still be the only option for sharing channels not using the deterministic key option requested here.

This works fine, you send the link.

[garthvh]

Channels with a known key require a lot of management, adding a ton more known keys to be managed on device and over MQTT would create a lot of mesh traffic for pretty limited benefit.

[Dokument]

Thanks for the feedback.

It is unclear to me why/where there would be a "lot of management" required? What scenario are you imagining where a ton more keys need to be managed?

Also, I argue that this would allow for a reduction of mesh traffic. Both in channel sharing over the mesh for these types of channels, but also in the one-to-many broadcast model I stated above.

[garthvh]

The default key is considerably more difficult to manage than private channels as everyone knows the key, there are privacy and traffic issues to manage. The default channel does more than 5 million packets a week over mqtt alone. Your proposal creates an unlimited amount of these problems to manage.

[Dokument]

Those concerns are tangential to Meshtastic's stated goals. Using the statement I provided would set clearer privacy expectations than the app currently does today. Also, I really do not think it is fair to say this feature request would result in "an unlimited amount of these problems to manage".

[garthvh]

You are really downplaying how problematic this would be, it creates not solves privacy problems.