Meshtastic Channel Support - Confirmation of understanding

Support
1

Hi - Wondering if someone can wade in and tell me if this understanding is correct in terms of Channels - and then onto Private Messages.

Imagine a scenario - 2 Nodes; one with iOS and 1 with Android (This is what I have been testing)

  • Default - out of the box - communication works on iOS “Primary” Channel to Android “LongFast” Channel (tick)
    Observation: the primary iOS channel when you go to settings / channels actually has no name.

  • And Direct Messages also work (tick)

So its a working solution.

Q. The Primary / Long Fast traffic is encrypted - but everyone can see and decrypt the traffic as it is using the default AQ== encryption. Correct? 99.9% sure this is the case.

Q. The private messages - I am unclear how these are encrypted. Can anyone clarify?

Now I change the configuration - making the original channel (the first channel) to a private channel by
a) Changing the name and b) Specifying a shared PSK

Q. I have good comms on this - and effectively it is a encrypted chat group for anyone with the channel name and PSK. Correct?

Q. And in doing so I stopped a lot of “data leak” of position and so on? (I mention as I think this is what the documentation means)

And now I add a second channel and:
a. Call it LongFast on Android
b. Call it “” (blank) on iOS
c. Set a PSK of AQ==

and I believe I have the public everyone channel back - correct?

So now I have best of both worlds - the public chat and a private chat room - I think.

But then I come back to the encryption for private messages again - and don’t understand how these are encrypted… any clues?

Thanks

2

Direct messages are not inherently secure…as they can “channel hop” among any channels shared by the two nodes in-question, even if one of those channels is “in the clear.”
See the Encryption segment of the docs

Direct messages to a specific node (e.g. text, traceroute or position requests) may use any channel you share with the recipient. Namely, the device will use the one where it most recently heard a NodeInfo packet from the recipient on. Client apps will not show messages directed to other nodes, but in principle they could be read by anyone who knows the used channel key. This means that if it uses the default key, you have to assume anyone could read your direct messages.

For truly secure 1:1 comms, use a dedicated channel with unique encryption key. There’s no other way to guarantee only the two nodes in-question may decode the packet.

There’s a long discussion about this and why Direct Messages were never meant to be a security feature, but a utility feature in this PR.

I understand the logic behind it, but it’s a hard thing to convey to new adopters in a concise UI friendly way.

Also, I didn’t see you mention it, but by naming your primary channel something non-standard, you may have inadvertently shifted your LoRa frequency…fine if all you want to do is communicate over that non-default channel, but since you want to also communicate with the LongFast/Default “clear” channel, take a look at this segment of the docs:

If you would like your nodes to include/expand the “public” mesh, you must use the default modem preset LONG_FAST . If you change your PRIMARY channel name, you must manually set the LoRa channel to the default for your region (see above).

You’ll probably want to set that for your geographical region…20 in the US, otherwise the hashing algorithm will set that to something non-default and you’ll never hear others over the open-channel.

Best,
Pol

3

Thanks Pol - RE: Direct Messages - all makes sense - thanks for the suggestion (as it actually makes everything clearer)

For truly secure 1:1 comms, use a dedicated channel with unique encryption key. There’s no other way to guarantee only the two nodes in-question may decode the packet.

regarding - you may have inadvertently shifted your LoRa frequency… - I “don’t” think I have… why?

  1. On Channel 1 (0 being the original LongFast which I have renamed/changed PSK on) I have called the channel “LongFast” and set PSK to AQ==
  2. I sent out a “test” and someone I don’t know replied confirming receipt - as a public test - so seems to be working.

In terms of my Lora Configuration - it read EU_868 for Region (I am in UK) ; Frequency Slot 1 (which I believe is correct for Europe) and Frequency offset is 0 (Zero).

So by my reading - I’m still good in terms of sending/receiving public messages and also having my nodes include/expand the “public” mesh.

Would you concur with my conclusion - or am I missing something?

Thanks in advance

4

In terms of my Lora Configuration - it read EU_868 for Region (I am in UK) ; Frequency Slot 1 (which I believe is correct for Europe) and Frequency offset is 0 (Zero).

In EU_868, you are fine because there only is one slot.

In other regions, the frequency slot is calculated from the primary channel name. So your primary channel needs to be the same or you need to override the slot setting there.

1 Like