We need to make secure p2p messaging easy so we can focus on building the other software.
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.
Haha, Yes! I hate competition with a passion. For example, who the hell cares about my p2p protocol? I don't, which is why I will use GNUnet in a future version. I wrote my own to learn and don't feel the need to compete with much better works.
My point is that nowadays there is a focus on writing for a client/server arch, other than any other.
As a result, you get lots of open-sourced frameworks/libraries. The same doesn't happen with p2p.
In my opinion, as we are having more powerful clients coming out everyday (more processing speed, more memory, etc) perhaps there should be an investment as well on trying to get something more out of that power other than rendering heavy client UIs.
P2P in many ways IS easier. The same code is used with all peers. While client/server typically has two separate code bases. P2P either client can start in any order, while client/server, the server typically has to be running first.
There are many more examples why P2P can be easier to write.
Can really use p2p technology on a mobile? I assume it would be required to be actively online all the time and drain the battery. If it avoids being actively online, then all mobile users are leeches.
Federation or a central solution is more efficient, since it uses less resources.
The only tool that's free software and doesn't use shady crypto at the moment seems to be Signal (TextSecure) which is not a great messaging app UI-wise. Perhaps a couple more do exist as well, but I don't see a plethora of actually secure tools around. Remember, Telegram and similar crap do not actually count as secure tools.
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 want a WP, browser and desktop based version of Signal. I use it on my phone and it's good enough, but I need an integrated experience with my computer.
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.
My point is, I think the area is too immature at the moment and needs a lot more innovation before we call for standardization.
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.)
Perhaps the conclusion is that we need to focus on a proper secure implementation of the underlying communication. If a standardized decentralised p2p communication overlay network exists, we can build tools on top of that, including IM and practically any other tool that can be implemented with messages.
Why isn't there a tool with iMessage-quality UI? I find it hard to understand why the demand is not being met. Could it be that a core tenet of a secure app is being open source and open source is less profitable, thus removing incentive. The article suggests it is because efforts are fragmented, which ostensibly is true. Maybe a combination of the two? What am I missing?
This [...is less profitable, thus removing incentive] is probably true, unfortunately. I personally seriously considered this space and actually wrote a quite complete prototype with this exact goal more than a year ago, but eventually decided to not move forward with it at the time. One problem is that it is really hard for an average user to distinguish BS security claims from proper crypto. An average user would likely consider Snapchat to be more secure than an E2E app.
Mulling on this a bit more - the profitability is further impacted from the inability to mine customer data on a secure app. Anecdotally, when presented with a free unsecure app vice a paid secure app, average Joe will go with the free app. Maybe there isn't a true demand like eps mentions
On iPhone, is it even possible to distribute software that's open source in the sense of being verifiable? It's all binaries coming from a central server. And the operating system code is secret. Maybe all your keystrokes are sent directly to Obama so he can scan them for terrorism.
It is now possible to compile your own binaries and deploy it yourself without paying $99.
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.
Yeah. I guess if you have Xcode installed it's even quite easy. Of course, push notifications won't work.
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'm often wondering if something like a mixture of the organizational setups of e.g. the Mozilla foundation, Kickstarter and Wikipedia could work for efforts like these?
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...?
> Signal (TextSecure) which is not a great messaging app UI-wise.
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?
The main problem I have with Signal is that it's funded by the US government (see https://news.ycombinator.com/item?id=8106721), which was the main reason for me to switch to Threema.
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.
In my personal opinion: if you want to communicate securely, with a very low probability of eavesdropping - use voice chat in any of modern games, on any platform. On both PS4 and X1, voice chat communication has to be encrypted(it's a compliance requirement), but at the same time there is no requirement that you have to implement a server relay - so a lot of games don't bother doing it, and it's a straight up P2P mesh implementation. You have encrypted, P2P traffic, not stored anywhere, that you can create an anonymous account to use.
Yep, but pretty much all games implement their own voip, in addition to system chat(Party Chat) - and while system chat can be forced to relay through MS/Sony servers, custom implementations in games do not have this requirement. They can also use different encryption to the system one.
I am also a game developer, and I have recently been working on implementing a voip system in a game. Sony/X1 requires you to use an "approved" encryption scheme, but they don't actually require you to store the key with them, or implement a server relay(which would allow them to intercept all traffic easily).
I did not implement VOIP on PS4 but I know for a fact that on 360 and XB1 the encryption for VOIP data can be entirely disabled. In case of XB1 they make you provide files to strip the voip stream from the rest of your game packets for this very reason.
> 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.
When you say its bound to Google, do you mean that users rely on play store to get Signal, or something else?
> Telegram has broken crypto, doesn't ecrypt by default and the authors being arrogant about their broken crypto doesn't exactly inspire confidence.
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.
> Telegram has broken crypto, doesn't ecrypt by default and the authors being arrogant about their broken crypto doesn't exactly inspire confidence.
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.
This is absolutely dangerous thinking. There are a lot of people researching crypto and making sure it's secure. If you're using non-standard crypto, you don't have that safety net.
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.
> This is absolutely dangerous thinking. There are a lot of people researching crypto and making sure it's secure. If you're using non-standard crypto, you don't have that safety net.
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.
>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.
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.
> 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'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.
> 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.
Cryptography is not "off limits". Cryptography is just a place where Not Invented Here approach is not just stupid, and incompetent, but dangerous.
There was a TOR talk where a person from China told that he recommended two systems to different people: TOR and some other one. The people he recommended the other one ended up in prison.
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.
There is a big gap between "this obviously looks bad" and "I have an exploit for it". There are many things that one should obviously not do and you can legitimately strongly advise against, but are not easy to demo an exploit for. The bar for accepting potential security issues should never be set as high as an exploit demo.
As someone who is outside of the security research community, the repeated assertion that "telegram is broken" is rather hard to accept without an example exploit. I would really appreciate if someone with the knowledge of how to break something like this took the time they would spend writing a blog post about it being broken and instead demonstrated an attack.
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.
I know there's a big gap between the two. But again, given the duration, amount, and variety of the "heat", at least something tangible would be nice. What if it remains like this for another year? Ten years? Fifty years? Will it still be called "insecure, because it doesn't use what 'everyone' else uses"?
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.
Telegram lost it credibility in how they handled criticism when they firs launched. They were arrogant ("look at all the programming world champions we have. If you don't have an exploit STFU" type of talking). The criticism people came with was valid.
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.
> are closed source, so they are completely unverifiable.
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.
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.
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.
In the end, I think that something using WebRTC combined with something like keybase.io to hold public keys as a lookup system could work.
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.
WebRTC as in a browser? How do you verify peers? As far as I've seen and understood, WebRTC's trust model is the same as the webpage's model - you must trust the page.
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.
Each client has a key pair, their public key can be published, such as via keybase.io, you get the public key, and send the message that only the corresponding private key can handle.
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.
But inside the browser, how do you actually verify the media path is secured properly? You end up trusting the server of the webpage you're on, since that's what negotiates everything. And if you trust the server, then you can just offload things to the server in the first place, and going P2P doesn't really matter.
Outside of the browser, sure you can negotiate your own way and tie the media to an established key.
Is that different from trusting whatever system delivers your desktop/mobile apps? Download over HTTPS from an reputable app store or web site. Or embark upon building and verifying it from source, which you can also do in the web app case.
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.
Why would a closed source client from a company known to be scummy (looking at what they did to uTorrent) be something anyone should pay any attention to? (FWIW I did check it out, but it wasn't better than Telegram, nor was it better when it was released than Signal is now.)
It's not clear why anyone would care, but a basic concept might be that making umpteen tools throws them all into the bucket of "wasting time on something that won't exist in a few years" while hindering the products that will.
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."
> 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.
Totally supporting this. As always in that kind of thread I feel it should be mentioned though, that easier to use is never, never, never ever more secure. Yes, less clutch means more secure. But if you ever think you can just start any computer and do something secure, without checking, configuring and understanding your environment, then you live in a dream world. Higher security means having more control of the environment, and that might very well mean understanding some physical and mathematical boundaries. "just starting to do X securely" (with X possibly being communicating with someone else) is impossible.
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.
83 comments
[ 3.9 ms ] story [ 94.8 ms ] threadI 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.
"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.
Federation or a central solution is more efficient, since it uses less resources.
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.)
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.
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...?
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?
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.
When you say its bound to Google, do you mean that users rely on play store to get Signal, or something else?
Easy solution: don't buy android
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
"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.
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.
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.