So the next device sw release (Tuesday ish?) will include channel level AES256 encryption. However, I’m not an expert on encryption. I’ve tried to do the ‘right thing’ and do standard solutions similar to projects I’ve done in my past, but no “encryption expert” has reviewed the implementation. So you should probably consider it ‘fairly secure, but don’t go planning anything super secret ;-)’.
If any of ya’ll are an encryption expert (or know someone), I’d love them to critique this:
@geeksville There might be a security concern to be addressed: the whole mesh could be compromised, if one device is lost. Therefore, we should be able to prevent external entities accessing messages and other data, if a node is lost.
This is especially important, for nodes left as uncontrolled repeaters.
An update on this: I just received a very thoughtful review by a security expert. They would like to remain anonymous, but sometime in the next weekish I’ll edit their comments into a new version of this document. It will describe current strengths and weaknesses and future ideas we might want to consider.
Ok - I’ve finally merged the great comments donated by anonymous crypto expert #1 (thank you!). I’ve also used those comments to extract a few simple/accessible tips/warnings about the level of crypto provided (i.e. what is your risk if an ‘attacker’ gets one of your radios in their possession):
Repeater nodes don’t even technically need to have the keys (though currently they do).
And one of the proposed work items (which is pretty easy) would make key extraction extremely difficult:
Turning on read-back protection in the device fuse-bits (this would extend protection in #2 to block all but extensively advanced attacks involving chip disassembly)
Though any of these ideas would be fine to do eventually as time and developer interest/hours allow.
btw: Initial experiments I did with Signal showed the the per message envelope size for a single message was at a minimum 1400 bytes(!). And this is particular to each participant, so when sending to groups per message keys have to be added for each recipient. A message of that size using our lora long range (high spread factor) settings would take about 42 seconds of airtime (assuming no lost packets - which is probably optimistic). Which for most applications I think would be too much to spend. Airtime is super valuable for a number of reasons:
Some regions (EU) place a duty cycle limit, which we should eventually enforce via code
Transmitting bits is one of the most expensive power consumers in our battery budget
Airtime is a shared resource across the mesh
Which is one of the reasons I opted for channel-level encryption, because the extra per packet cost is zero (because you can use the packet id and node id together to construct the IV for your cipher).
oh yes - I thought it looked really cool but I didn’t use it for this project (so far ) because they describe it as still very alpha (and I didn’t want to base a new alpha project on yet another also alpha dependency ). Also the only current implementation is in python, which wasn’t well suited for the initial mission of “a mesh that ‘just works’ using commodity $15-$30 off-the-shelf hardware (no PC required)”
But going forward someone (maybe me if no one gets to it first) should look at their ideas in detail.
Their implementation (https://unsigned.io/wp-content/uploads/2018/04/Reticulum_Overview_v0.4-1.pdf) is far superior to Signal and basic AES for Meshtastic needs and allows easier routing and couple/groups pairing than the other proposed solutions. The code can be rewritten in C and run on a uC too with some fixes.
The alpha status since 2018 is worrisome though, is it currently under development or just maintained?
@geeksville, you did list four measures, to strengthen Meshtastic security. All four are well justified. The order of #1-#4 could also be the prioritized order for implementation.
All the points you raised are valid and true. But we are constrained by the number of developers and the amount of hours they want to donate and work on. Currently it is just me, @Professr and @lgx as frequent contributors (and some other kind souls who have also contributed code & fixes).
So yes, doing more would be a good idea (and @Professr has a particular interest in OTP solutions). But what I was trying to get at with that sentence was: Work items 1, 2, and 3 from that document are fairly easy. And yes “burning the fuse bits to prevent readout” is technically security through obscurity, but IMO it will be a while before meshtastic is enough of a target that someone wants to do the the substantial work needed to attack such an approach. i.e. instrumenting an attacked PCB by drilling vias and soldering blue wires and using a logic analyzer to capture bits for a custom written reverse engineering tool.
So yes, doing something more than the listed work items is a good goal for ‘someday’, IMO it would take developer time for currently non existing attacks.
I’m all for practicality and prioritisation. I recognise the challenges of so few devs (I’m in a similar place myself). Needless to say, I’m looking at other more hands on ways I can contribute, rather than just making suggestions.
This project is great and is achieving a lot, so please don’t interpret my words as an imperative.
Also totally a fine option if someone wants to do the work - because reticulum looks really cool. (It is currently only written in python)
IMO - I think just from a timing/code maturity standpoint that’s more an option to consider 6 or 9 months from now. We’ll see how the work queues progress.
What can be implemented from reticulum is the individual chat which is encrypted so there would be a channel and a node. And not the dependency of a mac but rather more generic way. This is to allow more nodes.
Also from what I have read encryption they most efficient is chacha20 sand since keys are not sent over the network it can be 256 and for individual ecc based curves. I will try to find the paper that talked about this in the esp32. It also makes a difference in battery life.
) because they describe it as still very alpha (and I didn’t want to base a new alpha project on yet another also alpha dependency 
). Also the only current implementation is in python, which wasn’t well suited for the initial mission of “a mesh that ‘just works’ using commodity $15-$30 off-the-shelf hardware (no PC required)”