Crypto problems you actually need to solve(unhandledexpression.com) |
Crypto problems you actually need to solve(unhandledexpression.com) |
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.
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?).
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.
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.
In any case, there are no desktop clients yet that support OMEMO. Conversations and Jitsi support Message Carbons though (together with a compatible XMPP service, such as yax.im) very well. On the console, there is profanity that also supports it.
Yes, but UX is still the biggest issue. By all means develop next gen crypto tech: but first, make what we have now usable by people who aren't Unix people.
I would pay money for binaries of an Open Source GnuPG for OS X which wasn't awful to use.
Not in a tarball, not assuming I want to use the command line, on gnupg.org (with the angry SHA1 certificate warning fixed), not linked to from there for 'people who want GUIs'.
Yes, you can cargo cult the PFS algorithms over the email infrastructure, but if you save the temporary key, it's not PFS anymore, and guess what, if you want to save your message to reading later, you'll have to save the temporary key too.
That's not email.
Ok, that's less "instant" than most instant messaging system. But it has the same trade-off. It has a bigger time window when messages can be decrypted, and messages last for longer.
If you give-up on reading your email latter, yes, you can have some kind of forward secrecy.
When you change the public encryption key, you decrypt all messages received under the old key, re-encrypt with a local key, and destroy the private decryption key.
This way, someone getting your private encryption key cannot decrypt intercepted ciphertext he got before your last key change.
Obviously it requires to change PGP to get a new signed encryption key every time (unless there's some extension that already does it?)
I would love to simply sync users' keys between their devices and encrypt opportunistically like OTR does. Offline key exchange would only be necessary for verification purposes at that point. I see user key management as the harder problem than exchange.
UX runs deeper than software interfaces.
> Identity and key management is really the underlying issue
Yes, that's a UX issue.
So:
- Get GPG key from Facebook (which has them as part of the standard profile today)
- Say to person: you should contact this person by a means you trust and confirm this is their key (since we don't trust anyone by default).
- Once they click OK, they can now send messages to that person.
Nothing stopping other mainstream sites from adding GPG, it's jus that FB is the only one I know of. Obviously GitHub doesn't count since most people aren't software developers.
(You can build and use your own gpg binaries if you're concerned about their modifications)
- GPGTools isn't sure what's called. GPGTools? OK where do I download GPGTools? There's no button to do that. What's GPGSuite? Do I want that instead? Installed, there's nothing called either Applications/GPGTools or Applications/GPG Suite.
- Its app is called 'GPG keychain' or similar. Nobody outside crypto folk care know what a keychain or, not should knowledge of a keychain app be required to send someone a message encrypted with their public key
- The apps main focus is key management, and it's really poor at that. There's no way to discover people's GPG keys AFAICT
- It's a plugin for Apple Mail and a command line app. Most people using Macs don't use either of those. And it's not promoted as a Mac mail plugin, which means most people will be disappointed when they use it.
- It seems to choke on common GPG output with some chars. That output is probably not encoded correctly, that shouldn't matter. Be liberal in what you accept.
If you say no, it should clearly delineate how an attack could take place and advise you on how likely it is.
With your locally saved mail/messages it is up to you how to and whether to securely store them. You can save them decrypted if you are not worried about getting your device stolen. You can securely delete them if you think that you can not keep their content safe. You can do anything in between, it's your choice to make.
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...
2) Everyone and their mother understand that keychains hold keys. You have to get to a key somehow, the onboarding process is a simple wizard. Again, if you can't follow prompts to enter an email, enter a password, and wiggle your mouse around; no amount of simplification is going to solve the problem.
3) You use the search for key button...
4) I'd argue that the vast majority of Mac users, especially the ones that are not technically inclined enough to use GPG on cli but want to, use the built in Mail.app.
5) gpg seems to have a slew of text encoding gotchas, I'm not sure how those can be fixed without a lot of core dev effort
If you look at how keychains are usually used nowadays, they are an implementation detail you could and probably should hide from non-technical users.
As you say yourself, in order to find a key, you use the search for key button. Which prompts the program to look on a keyserver. You then import the first non-expired key you find for the desired email address. Why not do this automatically? You just annoy users who have to go through two (highly non-self-evident) steps and who do neither know nor care what a 'key' is. They just want to write secure email to their friends. (and btw, does the key-search even go over a secure connection with a pinned certificate? Because else you are not even trying to avoid MITM attacks).
Is it too much to ask these users to read the manual, learn about which kind of key is the most secure yet also compatible with the GPG versions of their friends, find out how many bits theirs should have, have them wiggle their mouse (why, couldn't you use /dev/urandom for most cases?), upload their key to a keyserver, search their friends key from a keyserver, learn about the web of trust and go to a key-signing party? Is this too much to ask? Probably yes. I did not need to acquire a similar amount of knowledge about TextSecure and yet it probably transmits my messages in a more secure form than GPG.
I am not saying that key-discovery is super-easy and all these are completely solved problems. But why do you have to make it so much more complicated for users than it has to be?
If clicking a prominently placed button to lookup a key is not intuitive, then how do these users manage the just as unintuitive process of finding, verifying, and installing an application on their device?
Keys are searchable over HTTP/HTTPS, and the HTTP derived (insecure) hkp and TLS-secured hkps protocols. The whole point of PGP is that you don't trust the source of the key without verification, so the protocol over which you receive the key doesn't matter.
There exist a plethora of implementations that hide the trust-building exercise from users, and they're all for instant messaging. You can shoe horn that into email, but why? PGP is based on the web-of-trust principle of verification; if you just want the attestation that UserX probably owns KeyX, use a service that's tied to your phone number or email that doesn't use PGP -- i.e. textsure, telegram, whatsapp, etc.
Installing GPGTools or gpgbanana, or whatever it wants to call itself at present however is hard.
2. Stand on street corner and offer free coffee to anyone who can explain what a keychain is.
3. Last time I checked there was no way to find an arbitrary person's pubkey in GPGTools. What directories does it use?
4. I'd say most use gmail. Mail server headers would back that up.
5. I can fix most with sed. If you see a bunch of equals signs and Unicode values, replace it with the equivalent Unicode character.
2) I could but I would go broke in minutes. 99/100 people would reach into their pockets or purses and pull out a ring full of keys and would intuitively understand that their computer uses an application to do similar. If your faith in people is so low you think they're all morons, why bother encrypting what they have to say. They're idiots anyways, not like they have enough mental capacity to plan anything according to you.
3) By default it uses either pgp.net or MIT's hkp servers, I can't recall. Most public keyservers sync their directories multiple times a day. You can search by name or email: http://imgur.com/a/SSHlP
4) How does using gmail prevent you from using the built in Mail.app or have anything to do with the headers not including gmail stuff? OSX provides a system-wide onboarding process for linking your gmail to all the system apps...
5) So you can send user generated input that doesn't match what they wanted to send. How is that helpful?
In the end, the current PGP workflow is simply unusable for many people [2]. It might be a good idea to introduce a new and improved encrypted email protocol, but since PGP/GPG are already here and had a lot of developement, why not make them usable for more people? What percentage of your emails are currently sent encrypted? I have currently two people whom I can send encrypted email; 99% of my email is currently not encrypted. I would really love to increase this.
[1] https://www.gnupg.org/blog/20150911-gnupg-this-summer.html
[2] Edward Snowden had a hard time convincing Glenn Greenwald to set up GPG. Even though he made a 12 minute video that detailed all the (horribly unintuitive for a non-expert) steps. So even with a strong incentive (possible whistleblower contact), the difficult setup procedure was enough to scare Greenwald away.
Additionally you think people who don't understand software that's complex to find or install are 'dumb'.
I stopped reading there. You should reconsider how you think about others.
Edit: you've edited your post and added some screenshots of the app store. Fine, I'll bite. There are good things in the App Store, this doesn't address the fact that the GPG site won't point you to any of them at all, that GPGTools has multiple names and the download link is off the front page, that MIT is not a mainstream directory of people, that knowing about keychains being a popular requirement for crypto does not means that it is necessary, or any of the other massive flaws in crypto UX as exists today that I haven't already addressed.
You said "Everyone and their mother understand that keychains hold keys." then agreed this wasn't true, and then twisted that so claim that I think people are morons. If you're not trolling (if you are, you're doing very well playing someone who has no sense of sympathy), you're missing the point: other people don't care about crypto, they just want privacy. Much in the same way you don't care about rack and pinion steering, you just want to go somewhere. That doesn't make them morons, it makes them busy.
