Please Stop Writing Secure Messaging Tools
dymaxion.org
dymaxion.org
GPG+email has UX problems meaning BFU's will never use it.
Signal is bound to Google, and Moxie's views on corporate control and calling getting applications from somewhere else than Google "going back to the old broken desktop security model" doesn't exactly inspire confidence.
Telegram has broken crypto, doesn't ecrypt by default and the authors being arrogant about their broken crypto doesn't exactly inspire confidence.
Whatsapp and iMessage are closed source, so they are completely unverifiable.
There isn't secure messaging tool that can be widely used as of now. I know not many people are good enough with crypto to be able to reliably write one, but that doesn't mean we should stop trying. Being able to communicate easily and securely is very very very important and should be part of basic infrastructure by now.
It seems that PS4 encryption is broken.
SMSSecure is a fork of Textsecure (Signal before it changed names) that drops all internet features and focuses on SMS only. So there's no Google dependency at all, and you get all of Moxie's crypto chops with none of his wacky views (it's on GPlay and F-Droid, with no fuss). I use it as my main SMS app, and so do a few of my (non-technical) friends and family. It really does just work.
The only downside is that nobody knows it exists. So it's hard to get people to use it, and it doesn't get the eyeballs it deserves.
When you say its bound to Google, do you mean that users rely on play store to get Signal, or something else?
Of course not embraced by the Signal team, but from what I gather it works most of the time. Sometimes getting messages can be a bit wonky, though.
Easy solution: don't buy android
They can still be verified by third parties if Whatsapp/iMessage wanted to do it.
No company can satisfy security purists, because they can't make a living out of it.
We have a secure messaging/voip app. Verified by a third party (they have the entire source code). We use the same protocol signal uses (Axolotl ratchet). You can install applications without app/play store and you can run the server on-premise on your own infrastructure. No google services are needed.
But all of that will still not be acceptable by "the community", because we are closed source and charge a license fee.
As a lay-person in this space, could you explain what's wrong with their crypto? Have their recent competitions not addressed Moxie's concerns? Would you be more comfortable if they published their server code (as they keep promising to do...)?
Their arrogance and will to power is rather mild in comparison to that of the people running Facebook and its properties. I'm happy not to see ads based on my private chats.
I find this "because it's not 100% standard crypto it's broken" mentality here questionable. Surely innovation can happen in the crypto space without having to be signed off by the usual suspects? Last time I checked Telegram's crypto was not broken.
Of course it does not end to end encrypt by default. Most people do not want that given the disadvantages this has in the user experience.
They're using primitives that are proven to be insecure against certain types of attacks (non-checked DH, MAC-then-encrypt, etc). And their code seems to be not perfect (https://twitter.com/matthew_d_green/status/58291636575066931...).
Signal on the other hand uses a variant of OTR (https://whispersystems.org/blog/advanced-ratcheting/). Which was thoroughly reviewed, and mentioned in NSA documents as not-cracked.
You can't just invent something and claim "last time I checked it's not broken". It's not broken (yet) if enough competent eyes looked at it, and the more standard building blocks you use, the easier to make those claims. That is absolutely not what Telegram does. I really wish the myth that Telegram is secure would die.
Absolutely dangerous thinking is to declare cryptography off limits. With that in mind eventually you just scare more people to participate in this process and eventually be left with a tiny core community.
And this discussion is very moot anyways as telegram uses standard cryptographic primitives.
> They're using primitives that are proven to be insecure against certain types of attacks (non-checked DH, MAC-then-encrypt, etc).
Except they are not using them in any insecure way and they are doing this for very good reasons. This Twitter thread is also full of misinformation collected together from an age old post that was itself misunderstanding how the protocol actually works.
> You can't just invent something and claim "last time I checked it's not broken".
Sure, that's exactly how SSL works. We invented crypto systems and we are using them until they are broken, then we phase them out for something else.
Cryptography is not "off limits". Cryptography is just a place where Not Invented Here approach is not just stupid, and incompetent, but dangerous.
That should apply equally to all parts of software engineering and with a big exception that says: unless you know what you are doing.
This kind of consequences you get when you falsely claim security. This is the main reason I want people stop saying that Telegram is somehow secure. It's just another messenger, people who need security should use something else. There must be no confusion about it.
Anybody can participate, just don't claim it's secure.
> Sure, that's exactly how SSL works. We invented crypto systems and we are using them until they are broken, then we phase them out for something else.
The only difference is there's a maillist with actual cryptographers (https://www.ietf.org/mail-archive/web/tls/current/threads.ht...), that iterate over design. If you look at the history of TLS, you'll see how tricky is to get crypto right. There has been lots of attacks on the protocol, that no one person could've think of. You don't have that if you roll your own and/or have "very good reasons" when people point your mistakes out.
You'd hope so, but contrary to popular belief, actual cryptographers relatively rarely manage to prevent errors in the standards. For instance, Phil Rogaway warned against MAC-then-Encrypt used in TLS which led to the Padding Oracle attacks many many years before they were exploited, but the suggestions were ignored by the "practitioners" designing the protocols. In fact, the TLS example was one that is relatively easy to get right if the designers wouldn't have gone crazy and listened to actual cryptographers. Telegram will someday fall into the exact same bucket.
The best description of it seems to be at https://github.com/trevp/axolotl/wiki and it's not really understandable by someone who doesn't already know the protocol, so I doubt many people that don't work on Signal have reviewed it.
It looks like the authors know what they are doing though, so it's probably good, but there might be a small risk that they overlooked something.
As far as I know there's been one whitepaper on TextSecure itself (https://eprint.iacr.org/2014/904.pdf).
Aren't they using "their own" crypto just on top of standard methods?
Having relatively low security requirements (I simply don't want to see ads based on my conversations), I'll continue using it to talk with my friends and family until someone demonstrates an exploit.
After half a year a russian guy found that the server could backdoor and later decrypt any newly started secret chat. That wasn't very confidence-inspiring back then. Looking at their security documentation now is _still_ painful. What better lesson to not roll your own crypto is there than having someone show how badly you borked it? They didn't learn anything.
Also, iMessage is not "completely unverifiable". In fact, there has been much work put in to reverse engineering iMessage, and there is a program that can analyze what keys are used to encrypt. Granted, this is not easy and reverse engineering is not a preferable way to thoroughly investigate and verify an app's actions, but to call it "completely unverifiable" is just hyperbole.
I am building yet another secure messaging tool called Firestr (http://firestr.com and https://github.com/mempko/firestr). Except it is designed to be a platform for building all that other software. Has a built in application editor and application distribution system.
I have already built file transfer, voice chat, white boarding, and game examples. I want p2p distributed software to be EASIER to write than client/server.
The execution might not be ideal and it is a very small project, but I hope the idea catches on and inspires something better.
My p2p protocol is a throwaway and the goal is to use GNUNet long term. The apps built on top have no idea about the protocol.
Federation or a central solution is more efficient, since it uses less resources.
"I want p2p distributed software to be EASIER to write than client/server"
Totally agree.
There are many more examples why P2P can be easier to write.
Therefore, I disagree. There is still no tool with iMessage-quality UI that facilitates messaging and has an explicit key exchange step that a journalist can easily use, so please carry on with writing usable secure messaging/encryption tools or contributing to the existing one(s?).
I really don't think people should write new tool, but contribute to existing ones, otherwise we'll end up with a fragmented space that no one uses.
Security in particular is an area that often requires breaking away from compatibility (not just in the technical sense, but in the social and network sense as well) to actually work. I worry that we would lose great ideas if we call for standardization too early and stick to the way we do things today, which sucks.
(Also, empirically, fragmentation in other domains, even relatively late in the game, like social networks did not prevent from one clear winner to emerge. I don't see fragmentation as a big issue long term. Perhaps it's even good to some degree for security.)
Companies are the de-facto vehicle to do something interesting and worthwhile together while making a living out of it as well.
Why not take that some steps further and divorce the concept from the often more mindless than not "we have to make a profit!" shareholder value yaddayadda...?
As for trusting the OS, it is true, but I would argue it is no better than running on an Android phone that you don't compile and deploy the OS for. There can be a hardware backdoor in your phone too. At some point, you will have to trust your infrastructure to a degree.
It's hard to trust anything after Snowden. I don't know why my smart phone wouldn't be spying on everything I say. If not now then next year.
Maybe for messaging, what's most important is decentralized anonymity. We can use code language to conceal secrets. For actual documents, we can use more trustworthy platforms, at the very least ones with non-secret operating systems.
I've been using it recently on android and it seems nice, are there some nice UI things I'm missing but don't expect to have? Maybe some other problems I've not run into?
You load app, which connects into DHT network... you search for a contact via keybase.io lookup, which then does a query to find the given contact, and all further communication happens over webrtc against the public key of the target user. Other key sources could exist, as well as other registries, or side-loading keys via other channels.
It could be distributed, anonymous and secure. The down side is there isn't much one can do to fight flooding attacks. Also, peer negotiation of "friends" might get interesting as well.
It wouldn't be too hard to create an initial client using electron, or similar.
And if not in a browser, why WebRTC of all things? It still uses rather ugly SDP (which, at least in SIP, still suffers from being originally designed as a multicast protocol for one direction - the offer/answer stuff is poorly grafted in and doesn't really work like people expect, though in practise implementors seem to ignore stuff and code it like they think it should work. SDP is also bad because it's a text-based protocol, and those are almost never unambiguously parsed even if the spec is technically OK). WebRTC is probably more secure due to high-quality teams writing browser-facing code, whereas even 1000-line SIP programs are laughably terrible.
WebRTC is also a protocol, intended for, but not necessarily tethered to a browser. I think given the distribution level of browsers, it makes sense as a communication channel. Not that it's the best protocol option, but it's relatively easy to interface with at a higher level.
Outside of the browser, sure you can negotiate your own way and tie the media to an established key.
The only thing that is missing is the ability to verify the download out of band on desktop. This might be addressed with a link/bookmarklet w subresource integrity?
With the client side web app there is still more transparency than a server side app, because in event of compromise the backdoored code must be served to your browser instead of staying invisible in the backend servers.
The other big advantage from P2P is operational independence, you no longer need anybody to bankroll the servers and bandwidth.
No, it wouldn't/shouldn't be a dedicated app, as a proof of concept, but could be very usable in that form.
In fact security gets harder every year, not easier, because our computers get more complex and harder to understand. If you have a smartphone it's really hard to even understand the hardware you have, because 90% of that computer is in a single chip. You can't look inside just like that anymore.
And besides all these technical issues there is also always the human factor. The most secure tool is only as secure as you interact with people. You can't improve that with a better GUI or something either.
She's not really saying "don't work on secure messaging apps," but something more like "let's not focus entirely on secure internet messaging, but also help nonprofits and other organizations with a diverse variety of secure collaboration tools."
The list is fantastic.
https://briarproject.org/how-it-works.html
> Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging tools such as email, Twitter or Telegram, Briar doesn't rely on a central server - messages are synchronized directly between the users' devices. If the Internet's down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the Internet's up, Briar can sync via the Tor network, protecting users and their relationships from surveillance.
"Your connection is not private
Attackers might be trying to steal your information"
as the very first thing I see is not really leaping over the first hurdle.