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.
1 Like
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.
Cheers
1 Like
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.
2 Likes
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.
i was thinking about the same thing…
some Solar-Node, placed somewhere that it could be found by someone else.
someone else just needs to press user button, then can connect by bluetooth and copy the channels QRcode. then read all the messages with own device… not even accessing the relay node any more.
solution:
no need for double encryption…
Put the router nodes on different , encryptet channel. (Channel A )
THE User-Nodes for Messsaging put on encypted Channel B (same modem settings).
the router nodes will forward all the messages of Channel B without being able to read messages.
someone with acces to A can only read status of other router Nodes. (Or put each router node on seperate Channel…) You can Use Channel A to read out battery-status and locations of router-nodes…
btw: the router nodes dont need to have a display…
As long as the node in router mode has the same lora config it will re-broadcast for channels that it does not have a key for. The QR code consists of the lora config and a channelset
1 Like
Welcome @Edward !
This topic was discussed with @geeksville quite at the beginning of this project. However, at that time, there were no resources to be assigned for this. Furthermore, as it was pointed out, no one has been contributing for developing this.
Regardless, a decision should be made whether or not to separate networking services and user interface (including payload encryption and decryption) to “standalone” components.
I think it is important, for standalone routers/repeaters, not to be able to decrypt payloads (messages) they transmit/retransmit. Furthermore, it is almost as important, for standalone routers/repeaters not to show other nodes positions. Revealed positions makes it too easy for someone to take down all stations, when the first one is found. 
Therefore, I strongly suggest to assess this issue. The first step would be using A and B channels, with different PSK-keys, as @kilroy suggested. As this can be done, @Eagle - this is already doable. 
The second step could be adding a feature to the Meshtastic applications for added GPG-encryption & decryption. This will increase the length of the payloads, but should be manageable, at least for demands of enhanced security. @mc-hamster should be able to assess possibilities for adding this feature.
These two first steps might satisfy the needs of @Edward.
The third step might be separation of the networking components, and the components of user interface and payload encryption. This would allow us to disable user interface (showing messages/payloads, and other nodes locations on the screen), and there would be no need for storing encryption keys, for main payloads, on standalone routers/repeaters. Moreover, a node could still be used as a standalone user node, if the encryption keys, for payloads, are set, and the user interface is configured. However, keys for maintaining the network (repeaters) would still be preferred for standalone nodes?
This third step would allow us to loose a standalone router/repeater, without compromising payload security, or locations of other nodes. Indeed, the net could become unstable, if the lost node was used to, for an example, to flood the net. What are your @garth thoughts of this?
Geeksville is happily retired and @mc-hamster is still the project leader but is doing more strategy and relationships and less firmware work at this point.
This is all actually working now in 2.0+ and I would definitely recommend using what we have before adding more functionality / complexity.
If you are using the default long fast modem setting I would just leave the default channel and lora settings on your node with device.role of ROUTER (the repeater project actually does not exist yet) and use long fast on your devices with customized channels. This way the router will retransmit packets on LongFast and physical access to that node will not compromise your channel keys.
2 Likes
hi @Edward, I have read (and re-read) this thread a couple of times and it is still not clear what your goal is. Are you interested in e2e encryption using a mesh? There are easy ways this can be achieved with the system “as is”. Trying to build a truly secure comms solution (i.e. secret, top-secret stuff) requires sophisticated crypto protocols that don’t marry well with the payload size limitations. There will have to be compromises and that’s why it would perhaps be useful if you could explain what the threshold/nice-to-have objectives are.
Nearly everything we’re talking about here can be done as a proof of concept without modifying the firmware code and be done with our Python API. My guess is 2-3 days of work for someone familiar with the API and the encryption libraries of Python. Even working around our payload limitations can be done with the Python API and a little creativity.
This would be on the application level, so it can be added to Meshtastic at any time. We’re not locked for this type of new feature.