I'm not familiar with the design philosophy of the original protocol, or if they decided the protocol should or should not attempt to impose any kind of a security model, but given that the project grew out of the same kind of ethos as HAM, I'd bet it was never a high priority.

That said, these exploits make the mesh untrustable and should be mitigated. If the devs don't want to implement fixes, maybe the answer is stripping out all encryption entirely and adding a plugin system that allows anyone to implement a solution themselves. They could even move the current broken implementation to a plugin and make it the default.

In the future, they'd only ever need to handle requests for maybe new entry points or tweaks to the plugin system.

If you're looking for a Meshtastic alternative which was designed with cryptographic security in mind instead of adding it as an afterthought, check out Reticulum and its RNode firmware which lets it use (most) Meshtastic-compatible LoRa devices as a modem.

Reticulum also has much more intelligent routing, can work over things besides just LoRa (including the internet), and (some) applications built on it provide reliable transport.

• https://github.com/markqvist/Reticulum/issues/116 - explains some of the obstacles
• https://github.com/markqvist/Reticulum/discussions/117
• https://github.com/markqvist/Reticulum/discussions/307
• https://testflight.apple.com/join/ftgW9n0Z - i don't know if this currently works; i only skimmed the above discussions :::
  caveat about the license

  The license of the Python reference implementation doesn't meet the free or open source software definitions because it contains these two clauses:

• The Software shall not be used in any kind of system which includes amongst its functions the ability to purposefully do harm to human beings.

• The Software shall not be used, directly or indirectly, in the creation of an artificial intelligence, machine learning or language model training dataset, including but not limited to any use that contributes to the training or development of such a model or algorithm.

While I very much appreciate the intention of these clauses, they will inevitably inhibit adoption somewhat.

There are however already multiple compatible implementations in development under free licenses, as you can see on the Awesome-Reticulum wiki page. (Including one by a company marketing products based on it for military use 😦)

The Sideband app is also under a non-free license (CC BY-NC-SA).

If I'm understanding correctly, they are actually addressing security issues. For example, they have a blog post called that one time at DEF CON where they discussed what happened and how they mitigated it in firmware 2.7.5.

2. I believe every single exploit we demo'd was previously documented in meshtastics bug tracker 1yr+ ago and were closed by the MT devs and largely ignored for a year.

3. When I began trying MT in 2024 the devs shutdown convos asking for security fixes saying people should use other comms tools if they wanted security. Rather than address fixable security bugs.

Well, that pretty much settles the Devs don't care about security.

this is never going to be and was not designed to be a secret spy movie text network anymore than it is an instant messager replacement. the encryption has a ways to go yes but its also come a long way. the benefit of the platform is zero licensing entry with cheap gear. that communities can stand up together and use. or organizers can flash devices between uses and swarm a mesh if needed.

its fun building meshes that can cover a hundred miles but, to function like that you have to drastically shorten the messages. and repeat messages to deal with drops. the encryption overall is fine for what the mesh can do and what the appropriate use cases could be. not great but it'll do.

Is it legal to encrypt communications in the spectrum meshtastic is using?

I had thought it was not and therefore could not be built into the protocol and so securing communications (potentially illegally) is left as an exercise for the reader.

Is that not so?

This is the kind of security research we need. By bringing up these issues, they can be fixed.

Yeah, I didn't have any current expectations about the privacy, anything beyond security-by-obscurity which is absolutely not reliable for any important private conversation.

I'm pretty much chatting with complete strangers on the network anyway, and the usefulness I see is as a secondary communication band if traditional networks aren't available in a crisis. The PSK sounded more like a channel filter than an encryption mechanism to me anyway (I hope my past comments describing meshtastic were clear about this).

I'm all for identifying these flaws and fixing them, improving the protocol in future version so that maybe eventually it can be suitable for sensitive information than hobbyist blather or emergency info.

My first thought would be to encrypt the profile broadcast with your private key and then broadcast it and then broadcast the public key second. That way, if the public key was not correct, they could not decrypt the profile broadcast at all.

Then again, I'm just a normie, so that's just a thought from somebody who doesn't fully understand the intricacies, so I could be way off base.

Meanwhile, radioamater enthusiasts chatting clear morse that you can listen from literally anywhere in the globe 🤣

As far as I remember, the end-to-end encrypted DMs are relatively recent thing in Meshtastic. Before, the messages were just encrypted with the symetric channel key.

The scale of meshtastics avoidance of building security into the design is pretty epic.

This is not an easy problem to solve. Each possible solution requires a trade-off.

Meshtastic's low privicy design is just dissappointing! I wish persistant identifiers were way less relied apon as they are given out freely in order for the system to work. Verry much NOT designed for urban areas or being in the presence of adversaries.

There should be "discovery" metadata, encrypted "known" and encrypted "well known" metadata, each with a diffrent encryption key that is given out in stages over a few round trips and maybe some user TOFU prompts and/or auto promotion on a timer. Brand new radios will gain trust with other radios.

"Known" gives an identifier and public key based on the context, maybe per gps area or per individual device.

"well known" being enough to preform persistant non contextual identification for the lifetime of the device.

Actions like karking a device as a "favorite" may also push it into the "well known" catagory.