Security and Privacy Comparison of Meshtastic, MeshCore, and Reticulum for LoRa Messaging

This is a public draft. Feedback is welcome.

Meshtastic and MeshCore are the two most widely known messaging platforms for LoRa radio communication. LoRa messaging over the Reticulum networking stack (RNS) is a less widely known third option that offers much better security and privacy. Portable LoRa radios running Reticulum's RNode firmware (paired with client software on a phone or computer) have been usable for years, but standalone LoRa repeaters with microReticulum firmware have only started becoming usable within the past six months.

The lack of easily deployed repeater firmware prior to this year seems to be a major reason why Reticulum has not thus far been a viable alternative for building LoRa mesh networks. With the increasing usability of microReticulum firmware, it becomes more relevant to consider Reticulum as an alternative to Meshtastic and MeshCore for LoRa messaging, especially for use cases that prioritize security and privacy. It is worth noting that Reticulum is a more general networking stack with many uses outside of messaging, and also that it is not limited to LoRa and can create links that hop seamlessly between the internet, local WiFi networks such as HaLow, and even long range HF radio.

The messaging protocol built on top of Reticulum is called LXMF, and one of its significant limitations compared to Meshtastic and Meshcore is that it does not offer group communications as a built-in feature. This will hopefully be added at some point in the future. Until then, groups can only be implemented using additional software that would have to be further evaluated for how it affects security and privacy, such as a server that does a mailing list style forwarding of LXMF messages to subscribed contacts, or posting messages to a Reticulum-hosted forum or chat room. These options are all much less convenient than the default group functionality offered by Meshtastic and MeshCore.

Encryption Security

The encryption offered by Meshtastic is very limited and does not even attempt to offer most of the protections that have been expected from encrypted messaging systems in recent decades: https://meshtastic.org/docs/overview/encryption/ MeshCore attempts to improve on this in some ways, but uses AES-ECB encryption that was known to be flawed long before they started using it, and has a number of other protections that are either not implemented, or implemented in flawed ways: https://github.com/meshcore-dev/MeshCore/issues/259#issuecomment-4060765626 There are ongoing discussions and proposals for improving the MeshCore encryption and fixing some of these problems, but the timelines for implementing these are unclear.

The encryption systems of both Meshtastic and MeshCore lack perfect forward secrecy, which means that if someone gets access to the private or pre-shared keys on any side of an encrypted conversation (such as through physical access to a LoRa client node) they can decrypt both past and future messages from that conversation until the keys are manually changed. In other words, there is no automatic key rotation built into the encryption system.

Reticulum uses strong, well-implemented encryption. From what I have seen, the only significant feature it lacks is quantum resistance using new asymmetric cryptography that started becoming usable a few years ago. This quantum resistant crypto involves much larger keys that would be a problem for key exchanges over limited-bandwidth radio links that are a primary use case for Reticulum.

Metadata Privacy

Every Meshtastic packet, including the telemetry that is sent automatically, includes a publicly-visible device ID based on the unique MAC address of the LoRa hardware sending the message. This ID cannot be changed, not even by reflashing the device. This makes surveillance of Meshtastic devices (and therefore users) much easier over time, and makes anonymity much more difficult. Discussion of this issue has been ongoing for nearly two years and the developers say it might be fixed in a future release but there is no specific timeline: https://github.com/meshtastic/firmware/discussions/5007

Every MeshCore packet has a routing path field in its publicly-visible metadata that shows which repeaters the packets has passed through on route to its destination: https://docs.meshcore.io/packet_format/ This provides at least some information about the geolocation of the sender, with the precision of a location estimate depending on the density of repeaters and radio propagation dynamics in the area. These repeater hops are provided in the MeshCore client interface to recipients of messages, and also publicly recordable by anyone listening to MeshCore traffic over the air.

The design of Reticulum prioritizes user privacy and keeps packet metadata to a minimum. For example, the unencrypted packet header includes only the recipient address of the packet, but not the sender. There is also an optional feature called Interface Access Codes (IFACs) that allow for a network name and password to be shared out of band to all nodes in a network (including repeaters) and used to fully encrypt all traffic, including packet metadata. When an internet connection is available, Reticulum traffic can also optionally be routed through more metadata-resistant and secure anonymization networks, such as I2P or Tor.

Device Security

Both Meshtastic and MeshCore client devices store all their sensitive information, such as message contents and encryption private keys, on the LoRa radio device. These are minimal embedded devices without encrypted storage or any other device security features. This means that anyone with physical access to one of these devices can easily extract all of the sensitive information and potentially use it to decrypt both past and future communications due to the lack of perfect forward secrecy.

For Reticulum communication over LoRa, all of the sensitive information is stored on the phone or computer running the Reticulum client software, not on the LoRa radio device flashed with RNode firmware. Therefore, this information can be much better protected by the encrypted storage and other substantial security features of the phone or computer's operating system and hardware.

On LoRa devices without a screen, both Meshtastic and MeshCore use a default pairing code for bluetooth. If this pairing code is not manually changed, anyone within bluetooth range of an unpaired device (such as in an adjacent room) can connect to the device and get access to messages and pre-shared group keys stored on it. The RNode firmware always uses a randomized pin for bluetooth pairing, even when the device has no screen. This is a small thing, but it also an example of how at all levels Reticulum development has made design choices that prioritize privacy and security, even when it is not convenient.

Conclusion

The points of comparison above are just a few of the major security and privacy issues with Meshtastic and MeshCore that stand out when comparing them to Reticulum. These specific issues point to a more general pattern: privacy and security have not been consistent design priorities of Meshtastic or MeshCore in the way they have been for Reticulum. Therefore, there are likely other aspects of these platforms that are not included above, or not yet publicly known, that are also problems from security and privacy perspective.

For example, in April of 2026 a software security researcher published a blog post titled "MeshCore's problem with security" in which they explained a significant vulnerability they found that allowed a remote user to wipe a node: https://alainx277.com/posts/meshcores-problem-with-security/ In addition to problems with how the MeshCore developers silently fixed the vulnerability without disclosing it, the researcher also noted that the code was written in a way that very likely contained many similar vulnerabilities, concluding "I cannot recommend using MeshCore for private or sensitive communication, due to both the handling of security problems and the general state of the codebase."

Reticulum software has had security vulnerabilities in the past, and will inevitably have more in the future. A design that prioritizes security and privacy does not eliminate these kinds of vulnerabilities, but it does mean they are usually more limited in scope, and increases the likelihood that they are taken seriously with quick patching and proper disclosure. For use cases that require greater security and privacy of LoRa radio communications, Reticulum/LXMF messaging provides a substantial improvement over both Meshtastic and MeshCore.

Edit 1 - Clarify LoRa messaging scope in title and intro.

The lack of easily deployed repeater firmware prior to this year seems to be a major reason why Reticulum has not thus far been a viable alternative for building LoRa mesh networks.

That is certainly part of it, but the other big aspect is the lack of Reticulum / LXMF clients on the mainstream app stores.

If you compare the "approachability" with for example Meshtastic, there the path is: 1) install client app from App/Play Store 2) flash firmware via their web flasher 3) start chatting. No ambiguity on what app you should install, which firmware to use, etc. We aren't quite there yet (and maybe won't even try to reach that level of monoculture)

As someone who came to RNS after usng both Meshcore and Meshtastic (I'm sure there are many of us), the security flaws - particularly around the ECB encryption - seemed like a glaring red flag in the face of the whole point of the project. You can scream "off grid" and "decentralized" as much as you like, and I get that it is not super helpful to conflate these concepts with strong encryption, but I was surprised that anyone I spoke to regarding Meshcore seemed to have little concern (or wasn't even aware) of the pitfalls of AES-ECB encryption. Maybe I'm relying too heavily on my own personal experiences here, but the Meshcore users in my area seem more like radio nerds more excited about playing with new toys than they are folks that are genuinely concerned about privacy, encryption and the concept of future-proofing decentralized networks "for the people" a la Reticulum. It also doesn't sit well with me that the Meshcore stuff is closed source.

I mean no disrespect to the Meshcore project and the work of Liam Cottle, but RNS is on a whole other level to Meshcore (and Meshtastic). Nomadnet alone elevates the usefulness of Reticulum as a potential alternative to the traditional internet, something that the other Mesh comms solutions simply cannot offer. I could write a paragraph praising the whole encrypted design of RNS "from the ground up" but I would be preaching to the choir here.

I think you've covered the space well, and I agree with @bergie about the usability issue with RNS. Also, there is another project that should be on everyone's radar and that is PRNS ... it's more than just a rust language port of the python RNS code. It's more usable with it's "hopspot" UI, you can bring up and take down interfaces (wifi/ble/usb/lora/others) without having to restart or reflash embedded devices. It runs full RNS so rather than needing to have an RNode as a LoRa modem, you can just enable a BLE/USB/Wifi/other interface on your embedded PRNS device and connect to it over reticulum from your other device (phone/workstation), so it has the convenience of an RNode (maybe more convenient and secure, because there's no BLE pairing), but the flexibility and utility of a full RNS stack. Check it out here : https://github.com/KenAKAFrosty/Prns. I've been using it on the new ESP32 V4R8 devices and I like it.