First of all, I am super impressed with my initial tests of Gotenna - with no special effort, I am getting excellent range on my Gotenna by just letting it hang at my belt, nearly a kilometer in suburban environment…
My question is around encryption: I have not been able to find any information on what protocol GoTenna Mesh uses for encryption. There are mentions of AES, but that’s just the Cipher, what I am looking for is how encryption is implemented - how are encryption keys negotiated between nodes, how does it work for encrypted groups chats? I kind of assume you are using generally accepted protocols for key establishment (Diffie Hellman family) since coming up with a proprietary algorithm is most often a recipe for disaster It is already difficult enough to implement well accepted protocols properly!
So any detail on how you do this would be really welcome.
Private 1-to-1 and group messages sent over goTenna Mesh are end-to-end encrypted with 384-bit elliptic curve public-private key ciphering. The only exceptions are messages sent using the “shout” and “emergency” features which are by definition public conversations with others within range of you.
In our out-of-the-box encryption, we used these open-source libraries: CryptoPP and BouncyCastle.
Please note that while our own team values encryption (and privacy), we don’t pretend to be encryption experts (or even an encryption company — we’re focused on the whole mesh network thing, ha!) so we invite anyone to use our open SDK and substitute in their own preferred encryption scheme.
(P.S. Glad you’re enjoying your goTenna Mesh devices so far, @elafargue)
Thanks @danielagotenna - yes, ECC, not AES, sorry Thanks for the pointers, and well understood about the goals - I completely agree, decent crypto is a nice capability for Gotenna Mesh but not central to the Mesh concept. If you had a quick comment on how you do key agreement though, that would be wonderful!
You should get a crypto expert to look at your implementation. It is not super hard to get someone to look and they can usually explore it in 1-2 weeks of work. But if you get just one flag wrong, one IV generated wrong, one buffer protected incorrectly, one hash moved around incorrectly, the entire scheme is worthless and can be unrolled trivially by an expert.
I can suggest such experts if of use offline. Sadly I’m not one.
Our end to end encryption has been reviewed by various external experts.
We actually made some changes in the past year due to some feedback we got,
and are always open to more
That’s great to hear. I’ll admit your comment above was scary. Getting experts to look is the only way. Iteration over time with more and more eyes is the winning play here.
Is this code open source? If so I’m happy to have my crypto friends look.
It’s tough for me to trust something that is a secret which is why I like open source encryption. I’m hoping encryption will be a topic @Rahul_Subramany will include in one of his chat sessions. I imagine there must be some universal interest or they would not have put encoder rings in our cereal.
I saw some bouncy castle references when I was playing with the SDK yesterday but I have not explored those yet. I’m still working on basics. I’m playing with Ifttt integration. I have no idea how I will do key exchanges at this point.