Hi Gotenna,
From the marketing material and previous forum discussions, I understand that the protocol used for message encryption in the bundled app uses standard cryptographic primitives and has been reviewed by experts.
Is the actual protocol documented anywhere, and are the review reports available?
I don’t know much about encryption, but goTenna Mesh makes use of CryptoPP and BouncyCastle encryption libraries.
If you want to sub your own encryption, that’s possible by using the SDK.
It should be noted that this is tactical grade encryption, i.e. if you want things secure for a time, it’s workable, but for state actors with access to resources it’s something to be used with suitable caution. Anything passed wirelessly is subject to such attacks.
Hi @MikeL, thanks for your reply and I really appreciate your intention, however as you said you are not a cryptography expert. However, since I assume you work for Gotenna, could you please help get my message in front of someone who can provide the information requested? Thanks in advance.
PS: What do you mean by “tactical grade” encryption? Is it good or bad? 
I am not a employee of goTenna. Your message here gets it where they can view it.
Tactical grade encryption is neither good or bad. It simply reflects the fact that all encryption systems are subject to attack and being broken. The amount of resources, skills and time required to break them varies.
Tactical grade means that the system is secure enough for day to day use. Even if broken, it will take enough time that the facts revealed will no longer have much relevance. For example, where you’re at and what you’re doing might provide info to your disadvantage if it was transmitted in the clear today. Tactical grade encryption makes sure the key is long and complicated enough that time will pass to the extent that action could no longer be taken based on the info revealed if decrypted. In most cases, even state level actors would be slowed or stymied in using such info if protected by tactical grade encryption.
High level (or strategic) encryption has keys and other attributes that could take years and/or require high level resources (like extended/extensive processing power on computers) typically used by nation-state actors to successfully attack. This tends to discourage even mounting such attacks unless there is other info pointing toward its value.
Users of secure systems should never make the mistake of thinking that the immediate security provided is eternal. It’s not. Even if difficult or impossible to currently break, there are always new approaches to breaking codes, so that recordings of encrypted data can be mined later in case that is necessary. If there is something embarrassing, indictable, or troublesome you would not want revealed, then you should think very carefully about discussing it even on relatively secure systems. Only the user can make those choices, so it’s good to keep that in mind when you communicate. A secure system is not a Get out of Jail Free card, so don’t communicate over it like it is or you may regret it.
Thanks for the detailed explanation and advice. Now, while we wait for someone from Gotenna to get back to us with some actual information, here’s a follow-up question for you.
Based on your own definitions above, on a strength scale from 0 to 10, where 0 is LOL and 8 is the Axolotl ratchet algorithm (end-to-end encryption used in Signal / Whatsapp / Riot / etc), where would you rate the Gotenna default app, which most users will end up running?
Or, using my preferred definition of encryption as information timeshift, how much time would you say the Gotenna app buys me against an entry-level attacker? How much against a state-level actor?
For this discussion, let’s define the entry-level attacker as a high-school student who has read Schneier’s “Applied Cryptography” and the state-level actor as a stalker ex with a badge.
(edit: clarification on Axolotl algorithm)
Hmmm, well that WAS actual information. I suspect you’re asking about something that is, at least in part, proprietary information. I know there are some who insist that open-source is the only way to go, but everyone has opinions. goTenna doesn’t insist on its code being used, so there’s not much of an argument about open source to be had here. Roll your own with all the open source you want, it’s your option.
I’m not going to render this on a 0 to 10 scale, I’m just not qualified for quantization of such issues. I would venture that goTenna’s encryption is probably going to stymie the kid, but is likely vulnerable to high-level attacks. A quick bit of digging suggests that what goTenna describes as 384-bit elliptic curve public-private key encryption should be fairly secure. Wikipedia notes that the toughest code broken yet involved a 112-bit primary field accomplished by “using a cluster of over 200 PlayStation 3 game consoles and could have been finished in 3.5 months using this cluster when running continuously.” That was almost a decade ago, so maybe this has changed, but a 384-bit key should make for a fairly secure system. See:
https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Key_sizes
That said, if you’re conceiving of the question as “how much time would you say the goTenna app buys me…?” then your use case is probably a bad fit here anyway. You may want to review my earlier comment that those who really have something to hide should reconsider any use of encryption, because it’s better to cultivate and rely on your own discretion than it is to create a problematic yet to be broken document and then hope it won’t be.
Thanks @MikeL , once again I do appreciate your participation in this thread and I would love to debate you in a more suitable venue, unfortunately we’ve drifted so far off-topic that I can see the curvature of my original question from here.
Let’s wait until the experts make time to talk to us, then it will all make sense.
@armin You might find my recent efforts to integrate goTenna Mesh into the Signal App interesting:
https://community.signalusers.org/t/adding-mesh-based-off-grid-communication-to-signal-app/4723
I have not yet integrated the Axolotl ratchet algorithm for mesh communication, but it’s a step in that direction. If you have some expertise in this kind of thing, I would appreciate help getting it to work over mesh. Here’s the current PoC fork:
GitHub - remyers/Signal-Android: A private messenger for Android. (branch: gotenna)
Hi @MikeR, nice to meet you and thanks for the reply, Yes, more precisely you’re doing ECDH with SECP384R1, a fine choice.
My concerns are mainly about the key usage and management: storage, exchange, disposal etc, as these are usually the pain points in a cryptosystem rather than the choice of curve. Where can I read more about this?
Hey @rmyers, we finally meet 
Loved your presentation at Paralelni last month and I’ve been checking out your other work since then. Solid stuff.
Unfortunately as I’m not familiar with the Signal source tree I can’t be of any immediate assistance other than forwarding the link to a couple of friends.
However, my family and I are longtime Signal users and will look forward to giving your app some serious real-life testing when I get my first set of GTMs.
Good luck with your project, this can be big.
Hi @armin ! Thanks for the kind words of support, and sorry we didn’t get a chance to meet at HCPP.
Your offer to test out the mesh’d version of Signal is much appreciated, and please also connect me with anyone else you think might be able to help.
The ultimate goal is getting the forward privacy working, but it’s possible to test now in rough form using the standard goTenna encryption.
I’m not a goTenna employee, but I will try to help.
As MikeR said, the centerpiece of the goTenna cryptosystem is 384-bit ECC and the curve is indeed SECP384R1. Good catch.
There is a single long-term key per GID, used for both encryption and signing. The key is generated by the app on first run and stored on the phone in a weakly obfuscated form (encrypted with a strong algorithm, then the key stored nearby).
There is no algorithmic correlation between the user ID and the key (like in Bitmessage for example). Knowing either one of these can’t help to infer or validate the other.
The key exchange is an unauthenticated single-shot exchange. Each peer sends their public key to the other in an unencrypted, unsigned message and the app ingests it quietly with no further validation.
For the message encryption, an ECDH key is calculated, which is then fed , along with some pseudo-randomness, into a SHA256 based algorithm that derives the symmetric encryption key.
The actual encryption algorithm appears to be homemade rather than a known AES flavor as claimed by goTenna, but I may be wrong. I’m waiting for clarification on this myself.
The encryption is 100% executed and enforced in the app. The goTenna dongle operates on metadata only and doesn’t really care about the message payload. It will happily accept and forward messages containing plaintext, valid ciphertext or random noise, or even no payload at all. Of course, the app will dump most of these quietly.
Any specific questions about any of the above, ask away.
Thanks a lot @Legs, that’s the level of information that I was hoping to find, and it’s amazing that it comes from the community side rather than the business side of the ecosystem. If it’s OK to ask, is this based on published documentation or personal research? Where can I read more?
A question for both @Legs and @MikeR : From my limited observations and confirmed by @Legs’ presentation above, I can see some potential issues:
If unmitigated, these issues can be exploited with a laptop and a $100 budget. Are any of these mitigated in the current version of the Gotenna official app, and if yes, how?
I’m not a gotenna employee either. But here are my thoughts.
MITM on initial key exchange - while theoretically possible there are a number of mitigating factors here. First, being at the right place at the right time to intercept the initial key exchange transmissions. Secondly, as the mesh units communicate they are also looking for specific endpoints which the MITM would have to have advanced knowledge of in order to posit themselves as that endpoint AND know they are going to do an initial key exchange. As these radios have limited distances, especially in an urban environment the best I’ve clocked is 2.4km (only once) 1.3km (with repeatable success) with the most common between 500-700m I can’t see how anyone could play MITM during the initial key exchange with any modicum of operational success. And if the endpoints stay on the move that would make this exploit even harder.
Past traffic and key at rest I’ll talk as the same point because the key and traffic is stored locally on the phone. However, and I could be wrong, but these days most phone storage is encrypted by default. If not, then they should be. So one would need to know the secret to decrypt the storage containing both past traffic and key at rest. Assuming one isn’t stupid and uses a physical attribute (iris scan, fingerprint, etc) the attacker would need to know the secret. Assuming short screen lock times (and my phone on Android P has a hotkey to lock down the phone on demand - which I assume could be reprogrammed to wipe the device storage) the attacker would need that secret which I could forget. If I was really that worried about the secret I could have a password manager that generates a secret I could not possibly ever remember and would need to have a secret for the password manager that only I know. Now there are firmware exploits of SSD and other storage devices that we know all states are actively trying to find and exploit but those require significant funds and technical knowledge and if you are already a target of those people then it is game over any way you look at it.
To address the other point about data and key at rest lets say the app is updated to encrypt these at rest. Well, that now requires another secret. The end user would have to manage that secret like any other secret and not divulge that secret. There are ways, such as incarceration and other methods, used to extract secrets from an end user. Thus it is best to have a generated secret one could never possibly remember. But then the user has to manage that very complex secret some other way (such as a password manager).
And to address long term keys if a user is concerned about that they could simply generate a new GUID which generates a new key (even on an 10 minute, hourly, daily or weekly basis). Granted this means more chances to do MITM initial key exchanges but being at the right place at the right time again makes that a much more difficult thing to do especially if the two endpoints stay on the move. And the users on both sides would need to be able to exchange their new GUIDs with each other so theoretically done often enough in a secure, preferably in person but could also occur over a separate secure channel, GUID exchange. Project Fi just announced that they will use a VPN on both secured and unsecured WiFi and with apps like WhatsApp or Signal there are enough ways to side channel secure GUID exchanges.
One could look at integrating additional hardware like a U2F key. But again, this comes down to being able to manage a separate physical device. And loath the day their U2F key fails to function (ask me how I know this pain - I’ve since abandoned that route).
In short, security is hard. Hard because it depends on the weakest link which is the end user or physical keys that can stop functioning. Keeping secrets is not easy. As some point in time one has to decide if the existing system is “good enough” or it needs more attention. I think for a lot of end users assuming basic storage encryption is probably good enough for most of us. And if one is the target of a state actor then all bets are off at that point. Unless the target themselve is already a state actor with adequate state defenses.
A couple of good security folks to follow are https://www.schneier.com/ and https://krebsonsecurity.com/
It wouldn’t be very useful to grab a public key. You would need the private key to encrypt. You could substitute your own public key to each receiver but it begins to fall apart if you can’t stay in the middle 100% of the time. That’s hard with a mesh network. The app would recognize a third device was involved at some point.
Unless I misunderstood the key IS encrypted but if someone has your device they can access the decrypted messages using the app. You have bigger problems at that point.
I see some validity of this point although I still think you have bigger problems if this happens to you. If someone were sitting on you and monitoring all your traffic they could recover all your old messages once they found the key. Not an easy task with the frequency hopping. You would likely need to write a lot of custom code just to log the correct data or sort through it. Then you need to somehow get the key or wait until there is either an exploit or enough computer power to brute Force it.
If you have to worry about State level actors and people physically getting your phone you need to practice good security hygiene.
aspexin and giqcass,
Thanks to both of you for the thorough review of the issues, some of which I touched on in decidedly less technical terms earlier. As you point out, security in a system like goTenna depends on a number of factors beyond the encryption itself. One potential limiting factor specific to mesh networks is the limit on message length, thus potentially also limiting key length, although I suspect there’s room to grow for now. This is far from the case where someone can just easily pluck something from the air, process it, turn it around and then conveniently “read the traffic.”
If it’s really the case that…[quote=“armin, post:15, topic:3932”]
these issues can be exploited with a laptop and a $100 budget
[/quote] …then one would think that a more discrete approach to the issue would better serve those using goTenna Mesh. White hat ethics, even gray hat ethical hacking, typically doesn’t involve this sort of back and forth. If you have identified a security vulnerability that is of note, then a public forum is the last place to first trot it out – not that it has been here. Nope, you show your work discretely to those in position to fix things, then work together by contributing to developing and applying a fix.
To simply imply that there’s something amiss, notably without offering anything beyond invoking vague suppositions at this point, sounds more like fishing for info to damage reputations than it is pursuit of any specific problem that needs be fixed.
Of course, granting the benefit of the doubt over what armin’s goal here is, perhaps he’s a gray hat hacker and doesn’t want to expose him/herself to legal liability over some discovery found here? Worth a read/review here is: EFF: A “Grey Hat” Guide
However, the suggestion that goTenna should just turn over proprietary info to someone who just stumbles through the door and asks for it suggests armin somehow believes that folks at goTenna just fell off the turnip wagon. If this is just some clumsy attempt to do good, it’s not very well thought out one. I suggest trying this approach to bettering cryptography with Apple and seeing how far it goes.
More realistically, if the argument here is meant to be some sort of winding path approach to an argument about open source cryptography, it’s not a very effective one. Get to the point, if that’s the case, because goTenna, like many other companies, chose what they believe is the best approach to monetizing their innovation and investment, including treating important parts of their work as intellectual property. If you want open source code, then get to writing it, because choosing open source means DIYing it, not chopping at others doing what is entirely within their rights to manage as they see fit.
If this demand for sensitive data and insights into goTenna Mesh cryptography is intended to actually gain access to info that can be exploited with ill intent, I’m pretty sure it’s not goTenna that fell off the turnip wagon. Seeing “potential issues” ordered up with an implied insistence that goTenna is not being helpful or forthcoming enough suggests the goal here isn’t so much product improvement as a reputational attack.
Remember, the “problem” with most cryptography isn’t a lack of security so much as is allowing users to be lulled into the belief they need not temper their improper use of it, instead relying solely on its strength to keep secrets secure.
Nice to see that the discussion is warming up a bit. A couple of points for clarity:
Thanks for reading, and first of all, thanks for your input in this thread.
Moving on to discuss the specific bits.
@giqcass, that’s precisely what Man-In-The-Middle means, an attack to substitute the participants’ public keys with your own. It’s easier than it sounds.
@aspexin, the fact that the exchange occurs unauthenticated over a small stretch of airspace is making an attacker’s work easier not harder. Keep in mind, it’s usually not a stranger on the other side of the planet that you’re worried about. It’s the a-hole who knows where you live.
And @giqcass, capturing Gotenna traffic across multiple frequencies is a solved problem since, I think, Defcon '17.
@aspexin, yes, periodically generating a new ephemeral encryption key (not GID) and destroying the old ones immediately after use is indeed a pretty good mitigation. However, I don’t think this is done in the current version of the app.
@aspexin, if you need to rely on phone’s encryption and screen lock as your single line of defense, you’ve lost. Ask me why. 
@giqcass, if someone captures the device message store, they can read all messages that haven’t been deleted. If they capture the private key, they can read all messages, period.
@MikeL, I appreciate your passion but you’re in unfamiliar waters and on a collision course. Please relax and consider this:
I didn’t make this up, Kerkhoff and Shannon did. Seriously look it up. Me, I’m just a guy who likes to ask the right questions BEFORE clicking that “Buy now” button. I didn’t ask for anyone’s keys or passwords, just enough information to make an educated purchase decision. And whenever I can, I always try to leave the place better than I found it.
Sorry if this bothers you.
Just figuring out this “quote” feature, please bear with me.
Not really. The key encryption is a solved problem according to two sources: @Legs above and Donncha’s pyTenna work on Github.