I don't understand why you'd concede security to your competition; it is a genuine distinction. Most security people I know, and all the crypto people I know would choose your designs over those of the other designers in this review, not because of the quality of your application but because you're clearly a capable designer.

I worry about the message we send with this "the competition is insecure apps" stuff. Some of the tools in this review appear sound now, but started off in a state of profound unsoundness. Yours didn't. There's a reason for that which speaks to the underlying quality of your design.

What I really want is for everyone to be using secure communication tools all the time. Not just because it'd obviously be great if everyone were communicating securely day to day, but because in extreme events, people tend to use the tools they already have and are familiar with.

For the London riots, that was BlackBerry Messenger. For the Egypt riots, that was Facebook and Twitter. Maybe the next explosive event will feature WhatsApp? So my sense is that for tools to be attractive in moments where security is suddenly of really clear value, they have to first be attractive in moments where security is less clearly of immediate value.

You're right that security is always a genuine distinction, but it's perhaps not the most valuable one to most people. I certainly believe that if you say "here's an app that you can install on your phone, and it will make everything more secure without you ever having to look at it again or even know it's there," then people will install that app. But that's not what we're saying right now. I'd love it if people used RedPhone all the time for every call they made, but I know that it's still not perfectly on par or better than a normal phone call, so I know that people will have a hard time putting up with its usability deficiencies if they haven't seen or felt the direct consequences of the NSA warrentless wiretapping program (or whatever) yet.

This isn't to say that there aren't plenty of people who find it valuable for their work right now, just that I'd like for us to be setting our sights on the common case and delivering a product that exceeds peoples current expectations.

I think we're finally getting to the point with TextSecure where the normal day to day experience is as good or better than the stock Android SMS application, but we should really be chasing WhatsApp or Snapchat or whatever.

And totally, good cryptography is extremely important, and I think we should continue to be rigorous there, but I'm not entirely sure how to approach that with people that aren't actually interested in building secure products. Right now if you search "secure sms" in the Android Play Store, the first result is not TextSecure, but 100 results for apps with names like "extreme SMS locker pro!" that "hide" your SMS messages by doing hand-wavey things. We might ignore them, but other people aren't -- they have hundreds of thousands of installs. I have no idea what to do about that.

...the next step would be to be able to share contacts (WoT) securely, like:

http://www.mightbeevil.com/contacts/

using something like

http://www.mightbeevil.com/framework/download.html

I think he maybe meant that the competition is the incumbent apps that don't have encryption as their selling point.

Yes, I'm clear on that. But maybe it shouldn't be. At least those unencrypted apps send a clear signal to their users about the level of assurance they provide.

He's just making an observation about people's behavior, not saying whether or not people should behave like that.

Having tried to build a secure messaging platform, I can't agree more that, for the average user, security is so far below the bottom of the list of important things as to not exist. Unfortunately, for those of us who do care, the removes the network effects that make secure software usable.

It doesn't make how many calls or emails I encrypt if nobody I talk to can receive them. It is encouraging to hear people 1) understanding security isn't really a differentiator and 2) trying to solve the real problems securely.

I don't think the average user feels it is at the bottom of the list, rather the average user trusts webservices for various reasons without realizing how much insecurity and lack of privacy results from using common webservices. I think that is slowly changing though.

The problem I've experienced is that whenever I talk about software security with non technical people I get a lot of "I thought this dude was normal until he put on the tinfoil hat" looks and overall lack of interest.

The only time people become more aware of security is once they've suffered the consequences of a lack of security. To be fair, the only reason it concerns me is because I've been exposed to so many stories and somewhat have to deal with it in my field.

So it follows naturally that as incidents of security crimes and overreaching governments and corporations increase, then so will the awareness surrounding information security. It has to be actually happening to most for humans on a crowd scale to pay attention.

This is a genuine concern. "I don't have anything to hide" doesn't mean everyone's communication (and location) should be tracked at all times.

Thanks for pointing to your low-latency-switching strategies, was an interesting read! Although I see how it is great for a high availability strategy as a side-effect, I wonder why you did not want to make use of location information on the phone. I mean having the user send his coordinates with his first request would be the obvious choice, but privacy considerations could speak against it. But if your returned list of available servers for a region would include coordinates, the app would not have to establish connections to all the servers, but maybe just the closest X. That could improve the whole process and save a tiny bit of traffic if you had a lot of servers in every region. And what about having a list of all your available servers cached with their coordinates in an encrypted sqlite database then? Firewalls that filter the single domain that is queried for server information would not be as successful. On the other hand, old or compromised servers would have to get revoked regularily. Or Have you had more problems with the idea of phone locations and local server lists?

Hey moxie, your write-up about how you built your switching network was fascinating. Thank you for continuing to be an inspiration.

p.s. you have a broken link to https://github.com/WhisperSystems/RedPhone/wiki/Signaling-Pr... in the writeup for the text "write our own".

Thanks! (And thanks for the heads up on the broken link)

moxie, I'm curious how the "short authentication string" prevents MITM attacks — can you shed some light on this or point me to existing documentation? Thanks!

The SAS section of the ZRTP RFC has all the details: https://tools.ietf.org/html/rfc6189#section-7

But the short answer is that part of the negotiated key material for the call is used to derive two words from the PGP word list, which are displayed to the user.

If the users then have a conversation about those words and they are the same, then chances are that they have the same key material. In the case of a MITM, they would have different key material, and thus different short authentication strings.

I am not moxie, but I'll reply. The key thing is that a short authentication string is shown to both parties. Then it is the job of the parties to also verify by talking to each other that they are talking to the right person (authentication part). That is the key part -- using some other channel (not just he algorithms and the protocol to authenticate the counter-party).

Then the boring part kicks in and the way the algorithms works is that if you are convinced that you are talking to the right person, then the way the secret key is generated won't be infer-able to an eavesdropping party.

Now, if I remember correctly NSA has published a paper where they allegedly fooled this system by using voice disguise and a voice actor to basically play a man in the middle attack. Now this is highly subjective and based on the context, so take that with a grain of salt.

It's some sort of key fingerprint. You know the key you sent to the other party, and the other party can compute the fingerprint of the key they received from "you." If they don't match, someone changed keys in transit.

Does this assume that the voice channel can't be doctored? But couldn't a MITM attacker do just that — compute the "correct" fingerprint and speak it to the recipient?

Yes, it assumes an attacker cannot imitate the other person's voice without detection. If you introduce enough latency or have a system fast enough to do on-the-fly voice changing you'd be set. It's such a great, simple idea, I felt stupid for not having thought of it.

To be sure, the voice channel establishes before the verbal authentication. I see your fingerprint is "banana", you see "kitchen". We can chat and I can say "alright so banana, right?" and you say "yep, in the kitchen". An attacker would need to remove banana and kitchen from that voice conversation and put their own fingerprint words in.

I think that level of realtime audio modification is pretty out of reach for now, although I suppose if you introduced a lot of latency, you might be able to pull it off. It'd probably be noticeable, and you can keep chatting and confirming the phrase, so an attacker would have to be really on-the-ball.

Plus, this only happens the first time. After that, the client saves the keys, so you know you're good.

Okay, cool. It sounds like this sort of attack is very difficult for now — but I would rather be aware of it than not.

It sounds like RedPhone doesn't actually save the keys yet — it's a work-in-progress. But that makes lots of sense.