Hacker News new | ask | show | jobs
by devit 3911 days ago
Ouch, isn't that totally insecure?

Whatever place TextSecure is getting the key from could have replaced your girlfriend key with something else and be MITMing all the traffic.

The proper way to do this would be to have your girlfriend's phone display a QR code with her public key and have you scan it with your phone camera, or using NFC to transfer the public key if available.

3 comments

You can verify fingerprints (manually or via QR code, example screenshot: https://info.securityinabox.org/sbox/screen/textsecure-en-1/... ) if you're concerned about MITM. You will be warned and need to manually accept the new key if a person's key changes.

Your "proper way" requires people to actually meet before they can begin a conversation, which greatly limits usability (you couldn't even test the app without a friend sitting next to you - who would keep an app they can't even try out on their phone?).

Yes, using a central server should be possible, but the application should ask you whether your friend is with you and if you say yes, it should use the QR code/NFC method instead (which also has the advantage of working with people you just met and haven't otherwise added to your contacts yet).

If you say no, it should clearly delineate how an attack could take place and advise you on how likely it is.

IIRC, Signal/RedPhone takes a (truncated) SHA-512 hash of your phone number/email after verification of your account and sends that to the server, and does the same for your contacts. If there are matching keys, it does the exchange for you quickly and easily, and this is basically all the server does for 'user management' I think. So your friend can have their phone/email intercepted, but the central server isn't going to reveal much data or anything at least.

Second, you can verify fingerprints manually if you're in person. The biggest draw is there is no distinction between a user who you've simply exchanged keys with vs a user who's fingerprint you've verified. This is something the Threema messenger gets right. Trying to explain capabilities of the attacker and how you could be MITM'd to some random user is totally pointless and will just scare them, it's detrimental to adoption. It's far better to have a visual indication of how much relative 'trust' you have with your individual contacts, rather than write a novel implying there could be G-Men on the other side of the line.

Finally, for phone calling capability, the loop can be 'closed' through a second level of verification, because RedPhone/Signal give you a (matching) set of random words upon connection establishment, and each party says the secure words to each other before anything else. This was an idea taken from SilentCircle, I believe.

The idea here is that it is easy for a human to verify they're talking to someone they know simply if they hear their voice verify the words they're seeing, while it's probably going to be difficult for an attacker to imitate arbitrary voices on demand in real time to 'spoof' a human.

> but the central server isn't going to reveal much data or anything at least.

As moxie acknowledged himself [1], the space of "all phone numbers" is so small that bruteforcing suddenly becomes feasible. AFAIK they're still working on it but I'm not up-to-date on what's been done since.

[1] https://www.reddit.com/r/netsec/comments/1shi77/textsecure_n...

This is an option, and like I said, this will probably happen when I decide to get a new phone, because I imagine the key will change. And for the paranoid, yes, you can do the verification. My point was that initial exchange (which, in my mind, is the most nerve-wracking part of the whole PGP setup when dealing with a layman) is completely automated.

Plus, once I sent her a TextSecure message, I sent her an SMS to confirm that she received the first one. Now granted I guess someone could hijack her SMS too, but you could swap that out for any second-step verification of your choosing: an SMS, an e-mail, confirming in-person that we're receiving what the other person sent, etc.