It is mitigated in 2.6.11

That release mitigates a previous issue, where different devices would sometimes generate identical secret keys due to lack of entropy in their random number generation.

This is their response to the issues which this post is about.

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.

Yes, you can make a signature using the private key and anyone can verify it using the corresponding public key.

But, if the attacker can replace the public key they can also replace the signature with one made using their own key - so this doesn’t solve the problem of keys being unverified.

If public keys were actually verified, signatures could protect the other fields in the profile packet from being modified. You could also theoretically use signatures to authenticate key rotation, by signing a packet containing your new public key using your old private key. But this doesn’t really work in the unreliable radio setting where some messages are likely to be missed.

In asymmetric encryption, the private key is used for decrypting things which were encrypted using the corresponding public key. You don’t encrypt things using the private key.

The problem here is that Meshtastic doesn’t have any means whatsoever of ensuring that a public key is authentic, and they allow keys to be replaced at any time. Verifying keys out-of-band would be the most secure approach, but to enable encryption between nodes who don’t do that the thing Meshtastic should be doing is ssh-style TOFU (meaning that users must explicitly acknowledge when a key changes before using the new key).