That’s how proofs of concept and prototypes begin. Give it a shot. Use port “PRIVATE_APP” for the prototype (aka Port 256) and if this works out, we can allocate a more permanent port.
Roger that. I’ll have to l buy some hardware when I scrape together a few extra quid.
That app looks easy enough to use. It does however have some bad reviews on its encryption standard.
I have been playing around with open keychain all morning. I am starting to really like it because it is easy to use. It also has option between pass phase encryption and public/private key. Its is recommended by the guardian project, open source, and independently audited. It also integrates quite well with the clipboard.
Sorry to bring up my own message, but if someone knows the answer or can point me to the right documentation pages, I would be very thankful.
TLDR: Is there a technical reason why a repeater (relay node) needs to be able to decrypt the message payload ? If not, do we agree it would be a desirable feature to be able to configure a node as a relay-only, with parameters about what to repeat, but no key provided, so that hardware theft does NOT imply messages security break.
Makes sense to me, but I am still trying to read up on all the specifics of Meshtastic.
Just thinking out loud, but it might require two sets of keys. One key for the relay node to authenticate that the the transmission is coming from an authorized user/transmitter on the network even though it can’t decrypt the payload, and then a separate key to finally decrypt message by the final recipient.
This is interesting, however, I do feel like you’re kind of reinventing Nomad Network | unsigned.io but without the ~4yr development effort that’s gone into that project.
If the Meshtastic team are interested in exploring strong encryption, I wonder if working on the C port and then integrating Reticulum might be a good approach.
@Eagle It does not need to be able to decrypt the payload. As of now, each node has the key. In theory, the router can relay the payload without being able to decrypt it.
@Edward You are talking about an authorization key and a payload key. It can be done but someone will need to pick up this “feature”. The development targets for version 1.3 are locked if I am not wrong, so maybe this can be targeted for 1.4
Okay interesting. Thanks.