Can I trust MeshCore encryption for sensitive communications?

MeshCore Encryption Summary
MeshCore provides two layers of encryption:
 
Channel encryption - AES-128 ECB + HMAC-SHA256 with a key derived from the channel configuration. All nodes on the channel share this key. Note that public (no-PSK) channels and open hashtag rooms are readable by any passive listener.
 
Direct message encryption - ECDH key exchange (Curve25519 elliptic curve) with AES session keys. Only sender and recipient can read DMs.
Cryptographic Strength
Both AES-128 and Curve25519 ECDH are modern, vetted cryptographic primitives used in TLS 1.3, Signal Protocol, and other high-security applications. Note, however, that those protocols use authenticated (AEAD) modes, whereas MeshCore's mode of use - AES-128 in ECB mode with a short 2-byte authentication tag and static ECDH keys - is weaker than the AEAD constructions in TLS 1.3 and Signal. MeshCore direct messages use sound primitives (X25519 ECDH key agreement + AES-128) but in a much simpler construction than Signal. Specifically, it uses AES-128 in ECB mode, a short 2-byte authentication tag, and static (long-term) keys - so it does NOT provide forward secrecy or the ratcheting that Signal uses. Treat it as basic confidentiality against casual interception, not as equivalent to Signal for high-sensitivity traffic.
What Encryption Protects Against
 
Passive eavesdroppers with LoRa hardware - Cannot read message content with correct key management. (Public, no-PSK channels and open hashtag rooms remain readable by passive listeners.)
 
Casual interception of DM content - Without the key, an eavesdropper cannot read DM plaintext. Note, however, that because DMs use AES-128 in ECB mode, identical plaintext blocks produce identical ciphertext, so an observer recording traffic long-term may detect repeated or structured content patterns (for example, templated emergency-comms messages) even without the key. Avoid sending fixed-format sensitive messages.
 
Replay/recorded-traffic decryption - MeshCore's DM ECDH uses static long-term identity keys, not ephemeral session keys, so it does NOT provide forward secrecy. If a device's private key is later recovered, previously recorded DMs to or from that device can be decrypted. Replay resistance, where present, comes from per-message timestamps, not from the key exchange.
What Encryption Does NOT Protect Against
 
Physical access to your device - Private keys are stored on the device. Seizure of the device potentially allows recovery of stored messages.
 
Compromised network operator - A room server operator can see metadata (who is communicating with whom, when) and the content of room/channel posts that pass through the server; only person-to-person DMs are end-to-end encrypted and not readable by the operator.
 
Traffic analysis - Observers can see that radio transmissions are occurring, timing patterns, and frequency of communication even if they cannot read content
 
Social engineering - If a recipient shares a DM, encryption provides no protection
 
Channel key compromise - If the shared channel key is obtained by an adversary, all past channel traffic (if recorded) can be decrypted
 
Loss of forward secrecy - Because DM keys are static, recovering a private key compromises past as well as future messages; there is no per-message ratcheting like Signal's Double Ratchet.
Appropriate Use Cases
MeshCore's encryption is appropriate for:
 
Community coordination that you'd prefer not to broadcast publicly
 
Emergency operations where commercial networks are unavailable - but only as a supplemental, best-effort text channel. Mesh has no delivery guarantee, low throughput, and degrades under congestion; maintain a primary emergency-comms method and never rely on mesh alone for life-safety traffic. The encryption above provides basic confidentiality only and is not suitable for life-safety or classified-equivalent secrecy.
 
Private group communications within a trusted community
MeshCore encryption is not appropriate as the sole protection for:
 
Communications subject to legal privilege (attorney-client, medical)
 
Operational security against nation-state adversaries
 
Highly sensitive personal information
For these use cases, use end-to-end encrypted applications (Signal, ProtonMail) with LoRa mesh serving only as a transport layer to reach an internet gateway.