Add unencrypted payloads

[erayd]

This PR adds unencrypted payload handling alongside normal operation. The purpose of this feature is to support replay advertisements between nodes that do not share a common channel.

The mechanism is to simply attempt decoding of a Data protobuf prior to decryption, and if it is successful, then treat the packet as unencrypted. In order to minimise the possibility of encrypted data accidentally happening to decode as something valid, a magic number is also checked, and the decode is rejected if this does not match.

This PR depends on meshtastic/protobufs#798.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)

[GUVWAF]

Wouldn't it suffice to just have a magic channel hash for unencrypted payloads? Or combine it with the magic number in decoded.

If the magic channel hash doesn't match, we don't even need to bother trying to decode the protobuf.

[erayd]

Wouldn't it suffice to just have a magic channel hash for unencrypted payloads? Or combine it with the magic number in decoded.

I did check that first, and the channel hash is already fully spoken for - the hash method used returns any number between 0 and 255, with no reserved values. Are you suggesting that I hijack a value that might also be in use by a channel?

[GUVWAF]

Are you suggesting that I hijack a value that might also be in use by a channel?

You have to assign a channel hash anyway, so it would be good to not use 0x00 (used for PKI) and any of the hashes resulting from the default preset names (LongFast, MediumFast, etc.).
Channel hash collisions can happen now as well, so it should be quite robust against that already.

[NomDeTom]

Wouldn't it suffice to just have a magic channel hash for unencrypted payloads? Or combine it with the magic number in decoded.

Is this a case where one of the other supported single byte PSK might be used?

[erayd]

Is this a case where one of the other supported single byte PSK might be used?

To what end? An attempted PSK decryption plus protobuf decode is more expensive than just the protobuf decode on its own. Given that these packets are explicitly intended to be public, I'm not sure what purpose encrypting them would actually serve.

[NomDeTom]

To what end?

I'm just suggesting it as an alternative to the introduction of unencrypted payloads 😃

[erayd]

I'm just suggesting it as an alternative to the introduction of unencrypted payloads 😃

Do you have a mechanic in mind? This needs to work without requiring the user to configure a channel (which is currently mandatory for meshtastic PSK, so implementing this as encrypted would also require modifying the crypto logic).