44
MeshMarauder: someone finally published a tool to demonstrate how trivial it is to defeat meshtastic's DM encryption (by replacing public keys in profile broadcasts) (partyon.xyz)
submitted 1 year ago by to c/meshtastic@mander.xyz
14 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 1 year ago (5 children)

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.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] [S] 8 points 1 year ago (4 children)

    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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 5 points 1 year ago (1 child)

    I may be thinking of signing. The idea is that you would have a message that's only proven to be authentic if you get the corresponding key. I probably just have the wrong terminology or something.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 6 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago

    Err, is it just me or does the Android client stop exchanging DMs in an existing chat if a public key changes? I've had to delete conversations between my nodes to reenable comm after regenerating one node's public key.

  • permalink
  • fedilink
  • source
  • parent