OpenPGP really works
foo.be
foo.be
Signal isn't even that popular compared to other platforms like iMessage, but I bet more people use it than regularly PGP.
I was regularly signing messages with PGP on Fidonet all the way back in '93 (and trying to find people to swap encrypted messages with). It's a bit mind blowing that the useability of the successor program today, GPG, isn't much better than what people thought was kinda wonkish and hard back in the Compuserve days.
If big companies like Apple and Google were behind this, it could change, but I'm afraid this won't happen unless there is a sudden need for it.
Digital privacy for average consumers needs more than a brand behind it, it needs an obvious value. I don't think many average people actually suspect that email _can_ be tampered with so, what does "signing" it mean to them.
Moreover, when/if it enters the mainstream it will be plagued with "hacks" which degrade the user-perceived value, causing many to abandon it if it isn't free.
by "hacks" I mean the users will expose keys and then blame AES :)
End-to-end [1] is using OpenPGP.
But for messaging it's indeed very marginal. In open source projects' techical mailing lists and version control systems there is pretty much message or commit signing but that's a marginal group who does that.
I have to laugh that Snapchat has apparently solved the identity exchange problem and PGP is still stuck with these ridiculously baroque implementations.
Er, how? Admittedly I've only used it a few times, but the only thing that sticks out along those lines is the Snapcode system. How is that any different than scanning a QR code in OpenKeychain?
WhatsApp integrated¹ Signal's secure messaging protocol. Since then, at least one government was unable to compel² the company to produce unencrypted messages from users under investigation.
Given the popularity of WhatsApp, I think its safe to say a lot of people are now using a relatively secure messaging protocol.
¹ https://whispersystems.org/blog/whatsapp-complete/
² https://www.forbes.com/sites/parmyolson/2016/05/03/whatsapp-...
With signal/whatsapp, there is no way of even knowing if the code you're using "in app" is the code in github or in whatever rev wherever. Yes, I know reproducable builds -- but what stops the app fetching more code from elsewhere? Wanna bet there's a webview and some JS in that app somewhere?
It's nice to make things harder for the NSA to read, but this architecture seems to be just creating the illusion of safety and it's kind of weird to see how much advocacy it gets here when there are such obvious faults in it.
I'm not saying there's a better alternative, and congrats to all who are working on it and I'm happy to see it succeed -- but this isn't a solved problem and there's massive danger in trusting such things.
I'd love to have the time to really inspect whatsapp/signal to see what I'm sending/getting -- has anyone done this? Google isn't giving me much..
Yes its not perfect, but calling it a illusion of safety is just overly negative. If the NSA really wants you, they will get you, but that does not mean all your safty is illusion.
They do not know. But they must be educated because it is ethical.Why do people use Facebook instead of Diaspora? It's not because Facebook is better, works well, or is easier to use... It's because other people use Facebook.
Why do people use Skype instead of XMPP? It's not because Skype is better, works well, or is easier to use... It's because other people use Skype.
Why do people use WhatsApp instead of GnuPG or OTR? It's not because WhatsApp is better, works well, or is easier to use... It's because other people use WhatsApp.
It's always the same standard chicken and egg adoption problem. As shown in the article, GnuPG is used for package signing, commit signing, file encryption, and all sorts of things that don't involve many people. But when it's about communication, you can only use GnuPG if the people you want to communicate with use GnuPG too... and thus the adoption problem applies.
And the reason people initially used Facebook, Skype, and WhatsApp is not that they were easier to use or better. It's advertising. Notice how all of these are proprietary software made by companies with the means to advertise their software? You can bet people would use GnuPG, Diaspora, and XMPP if they had been advertised by companies like Facebook and Microsoft.
So if we want people to use open source software and open protocols instead of living in walled gardens, we need to advertise them. Advertising works.
I know quite a few non-techies who use VLC, Firefox, LibreOffice, and other OS advertising-less projects. The difference is:
1. Facebook, Skype and WhatsApp solved problems others didn't and became big. Now it's too late to fight.
Had Diaspora been around before FB, and as easy to work with (put name here, picture here, password here, friend here. You're all set up. Let's go), or XMPP been around before Skype (which is a very old program in internet time), or Kontalk,Signal, etc. been around before WhatsApp (find friends by number, not by username), they probably would have taken off (at least to some degree).
Google came late onto the Desktop scene (Chromebooks) and are not successful while the incumbent (MS) is good.
MS came late onto the mobile scene and failed, while the incumbent (Google) is good.
It was. XMPP, aka Jabber, started late 1998, the first version of jabberd appeared in 1999, the standards group started in 2002 and the RFCs were ratified in 2004. Jabber.org, the first IM service on top op Jabber/XMPP opened its doors in 1999.
Skype was first released in 2003, about 4 years after Jabber had already become a thing.
Just because something was there first doesn't make it win nor does it mean it will remain the primary/principle protocol/option :).
> It was. XMPP, aka Jabber, started late 1998… Skype was first released in 2003…
But XMPP didn’t have VoIP until 2005.[0] More importantly, XMPP and SIP don’t have a great story for NAT traversal and privacy. And corporations are shying away from open standards, e.g. Google Hangouts federation, or when Apple FaceTime was supposed to be an open standard.[1]
A very long time ago, before even Jabber was around, I played with PGPfone[2] on my 33 MHz laptop.[3] No FPU. 128-bit symmetric encryption. For voice, the processing power problem is solved to overkill. But PGPfone proved to be useless because it didn’t traverse NAT.
The ultimate lesson from PGPfone: NAT is inherently repressive. It divides the Internet into haves and have-nots, and most everybody is a have-not. If you want to contact another have-not, you must do it through the graces of someone who has public IP address space. That is why I started advocating for IPv6 long before any of my peers.[4]
[0]https://slashdot.org/story/05/12/16/070245/google-jabber-and...
[1]https://www.reddit.com/r/apple/comments/1xuzif/what_ever_hap...
[2]https://en.wikipedia.org/wiki/PGPfone
Chance might play a larger role than advertising in the early game, for communication platforms.
I'd be willing to guarantee that with a name like Diaspora, it could have never achieved mass adoption under any circumstances. Most people won't know what that word means. The name sounds terrible and unfriendly, more like a disease than a social network your mother would want to join. Diaspora is another example of engineers not understanding how to make a product, top to bottom, for the general public.
Facebook was at least the third widely adopted social network. It made it largely by targeting its marketing towards college kids. and expanding strategically and somewhat methodically. Other than its marketing, the only other reason Facebook did well was by becoming a programmer friendly platform. It was no better for users than the other ones.
The network effects of Facebook et al are entirely artificial! The beauty of the internet is that there are no real barriers to keep everyone in the same box. Instantaneous, exact communication is possible across the whole world now. "Other people can't hear me when I'm not using Facebook, so I have to use Facebook" is NOT an inherent problem in a digital system!
The problem is, simply, that the law in the United States, Europe, and most of the rest of the world explicitly makes it illegal to provide third-party federation systems that would bring that permeability to the "walled gardens" of the modern web.
The walls aren't really there. We don't need to install millions of miles of compatible cable to hook up diaspora and Facebook. We don't need the government to step in and do anything to stop the behemoths, we just need them to get out of the way. The web's natural mechanisms can solve this on their own if the USG stops putting developers and entrepreneurs in jail/financial ruin for trying to innovate.
Users need to be allowed to access sites with a browsing device of their own choice instead of allowing vendors to cut off access based on the use of browsing devices that preserve content, and then we need to update our copyright and contract law so that normal use of these browsing devices doesn't constitute infringement or breach.
Repeal the CFAA, fix the Copyright Act, retake the web from phony monopolies. Let's get these guys competing on merit again and make room for the revolutionary iterative improvements of the little guy.
Lets' get in a time machine, what I'd really like to see is an open protocol for VR ala 'snow crash' governed in the same sort of way HTTP is, while we're early days now I think we can probably assume that VR, somewhere down the line potentially 'browser replacement' in reach but I'm not really sure that can ever really happen though when we're building lots of isolated gardens which speak different languages -- as the way things currently are? Do you think the motivations of e.g sony or htc not to go down the same path http did are because of the CFAA and over-regulation instead of money reasons?
It seems to me short sighted quick returns, lock in and incompat are going to play bigger roles than govt reg in the next decades in stifling progress -- I'd like to hear your take..
If the government stopped allowing large companies to haul innovators to court for accessing the data that that company willfully shared with the innovator's browser, the wall, at least on SaaS-style services, would be broken as third-party federators would be free to come in and tranform that data into something compatible with competing solutions. The data would be able to flow freely and the user would be free to access the data through Facebook directly or through a competitor service, and products would need to compete for users on merit instead of taking one's social graph hostage.
The web enables this portability, but the government has set up rules (in some cases, inadvertently and through negligence) that stop people from competing on an even playing field. We need to fix those rules. CFAA, EULAs, and copyright for RAM copies is a start.
Sure, GnuPG works "well," for engineers. This post is written by an engineer, but engineers are no longer the majority of computer users. If you want to develop mass market products today, coming to terms with that is pretty important.
To even try to draw a comparison between WhatsApp and XMPP+OTR is absurd. For an engineer, maybe the latter is passable, but the billions of people around the world who want to chat on their mobile device, don't understand what a key exchange is, don't understand why they can't immediately see everyone in their address book they can chat with, and don't want to run their own server, it definitely isn't passable.
> Why do people use Facebook instead of Diaspora? It's not because Facebook is better, works well, or is easier to use... It's because other people use Facebook.
> Why do people use Skype instead of XMPP? It's not because Skype is better, works well, or is easier to use... It's because other people use Skype.
> Why do people use WhatsApp instead of GnuPG or OTR? It's not because WhatsApp is better, works well, or is easier to use... It's because other people use WhatsApp.
I'm sorry but this is just not true. Network effects are important, but there's a reason that people are using these networks to begin with. They work really well.
Something like WhatsApp may seem simple, but every little interaction within the app is perfectly polished in a way that GnuPG, OTR, or any XMPP client is definitely not.
> And the reason people initially used Facebook, Skype, and WhatsApp is not that they were easier to use or better. It's advertising. Notice how all of these are proprietary software made by companies with the means to advertise their software? You can bet people would use GnuPG, Diaspora, and XMPP if they had been advertised by companies like Facebook and Microsoft.
As far as I can tell, WhatsApp never spent a single dollar on advertising. Their entire growth strategy seems to have been word of mouth.
These companies have hundreds or thousands of engineers who work on these products full time every day, driving the products forward, making them better and better. That is not something an open source client is ever going to be able to compete with. It just isn't.
> I'm sorry but this is just not true. Network effects are important, but there's a reason that people are using these networks to begin with. They work really well.
There's a reason they use these networks to begin with, but I don't think it has much to do with them working really well. The network has to work well enough, but past that, marketing, chance and being an early player are all factors that I suspect are more important than how good the product is.
> As far as I can tell, WhatsApp never spent a single dollar on advertising. Their entire growth strategy seems to have been word of mouth.
Yes, there are other ways to get through the initial growth than advertising. Such as chance, or being there before everyone else. But the "word of mouth" is part of the network effect I am talking about, and it comes after the initial growth. They had to get some initial growth somehow.
> These companies have hundreds or thousands of engineers who work on these products full time every day, driving the products forward, making them better and better. That is not something an open source client is ever going to be able to compete with. It just isn't.
That doesn't match my experience and I don't see a reason it would. If we were talking about a web browser, maybe, but an instant messaging client is something pretty simple that it doesn't take hundreds or thousands of engineers to get right and make into a good product. Since an open source project won't have the strong incentives a company will have that are against the interests of the users (making it into walled garden, centralized, proprietary software that doesn't use open protocols), it won't take much for the open source client to be better. There is not much correlation in my experience between how good software is and how much money the company that created it has or how many employees it has working on that software.
While you are technically right, making a good (as in "usable") chat client takes at least a competent developer and a UI designer, and most OSS developers lack in the second domain.
Especially for XMPP, you also need to apply a number of extensions to improve the experience.
From personal experience as an XMPP client developer and XMPP Standards Foundation member I can say that most of the work is driven (slowly) by volunteers, and that there is more work than time. We are starting to cover the UX side of things to make XMPP easy enough to compete with WhatsApp, but we need YOU to contribute. ️
Signal is an application (in fact more than a simple application) that solves a more global problem (of communication solutions that uses asymmetric cryptography) which never was intended to be solved with OpenPGP.
OpenPGP is a standard. GnuPG, the tool that people are comparing with Signal (I think).
Strong intrinsic motivation is the only reason people use PGP. It took me ~3 months to get a critical mass of 15 or so people on to Signal as first port of call.
It is _just_ slightly more complex than using Twitter once configured.
Also the longer you use OpenPGP, the less keys need to be verified. The start is very hard, since you start with no trusted keys at all. The longer you use it, the more fluent usage becomes.
Have been using GPG Suite on macOS and the only problem is, you may not get support for the new macOS on day 1 since apple provides no API for Mail.app. And then again, giving Apple some time to figure out their bugs of the intial major release isn't a bad idea.
This is exactly what scares me and the point of my "I'm giving up on PGP" article. People holding on to keys forever, moving them from laptop to laptop, never rotating them and asymptotically approaching compromise... because it's the only way to ease the pain.
Unfortunately while these workflows are encouraged, the tooling doesn't exist to make it a trivial operation for folks not familiar with proper key hygiene.
After reading¹² about this subject, I believe a reasonable level of security and ease-of-use can be achieved through the following process:
1. Boot a live Linux distribution such as Tails on a computer disconnected from the Internet.
2. Create the OpenPGP master key.
3. Initialize the YubiKey with subkeys.
4. Store the master key offline using paperkey³ and a machine-readable code.
The YubiKey is secure and convenient enough for daily use; the subkeys can be easily revoked and the hardware reinitialized with new keys.
Master key operations such as key signing and changing expiration dates require loading the master key into the offline live operating system. Much more of a hassle but hopefully not as frequent as YubiKey use.
Printing the master key on quality paper ensures³ it will survive for a long time.
¹ http://security.stackexchange.com/a/51776/9252
I have yet to find an email client that will even do the simple search of the keystores for you. It's maddening.
And there are a lot of those problems! Maybe even the majority of them!
But PGP was designed for message encryption, and it's a poor choice for message encryption. The community is gradually converging on the idea that SMTP store-and-forward email is just never going to be cryptographically safe, and pretty much the only messaging application in which PGP makes any sense is SMTP email.
What's worse is, much of the PGP ecosystem really only makes sense in a messaging context. Which means that the complex parts of PGP, like key servers and subkeys and things like that, aren't really adding value, but still confuse and distract users.
Asymmetric key algorithms, where the key used to unlock the document is different from the key used to lock it, were long considered the "holy grail" for cryptography. With an asymmetric key, I can closely guard the "unlock key" (private key), but shout out the "lock key" (public key) from the rooftops or post it on flyers and anyone could send me documents in secret that only I could unlock. (That unlocks the next, and still current, major problem in that how do you as someone looking to send a secret document to me trust that the person shouting that night from the rooftops or posting that flyer is actually me, much less know which flyers to look for or that I might shout it sometimes from rooftops...)
PGP was the first software built "for the masses" that made asymmetric key crypto accessible to the "common computer users".
(PGP is also notable for attempting to build one such potential trust system to find/trust keys, the Web of Trust model. This is where most of the contemporary arguments about the value of PGP these days are targeted. The Web of Trust is a useful solution, but its a complicated solution that doesn't scale as well as it should and has a bad user experience with a sharp learning curve and a long tail of key management complications for even power users.)
I have a text file. I encrypt it using a key. I send you the encrypted text file. How do you decrypt it? You need the key.
If I can send you the key securely why don't I just send the plain message using that secure mechanism?
Public key cryptography solves that problem.
7-Zip is pretty awesome for actually usable encryption. On Windows, with the Explorer integration, you can just right click a file, select "Add to archive" and create an AES-256 encrypted 7-Zip archive that anyone with 7-Zip can extract just by entering the password.
It is the UX/UI experience that anger people to the highest point. Noobs like long time users.
Correct key handling (signing, revoking, publishing and sometimes doing actually the job) is a burden.
Nothing is wrong with the code so far. Much more whatever correct the software is, it is a pain.
My guess, is that true correct cryptography requires this burden whatever the algorithms are because ensuring identity are trustable is where the more work is, and no software can do it.
Hm?
Of course PGP is criticized for that, just less vocally.
- Authentication is off by default in GPG
- Even so, it's very complex, and most of the protocol isn't authenticated
[ This is problematic, because ciphers tend to be more or less easily malleable, so non-signed messages can be tampered with; this is also an issue for encrypting files symmetrically ]
(- Compression is on by default and makes everything super-slow for no good reason)
- Widely used defaults for encryption and key derivation are rather arcane (eg. CAST5)
- PGP signatures, by principle, are non-repudiatiable, unlike most modern encrypted chat applications, so they prove to _anyone_ _forever_ that your key signed that message.
- PGP format announces all recipients to the world
- No forward secrecy possible
- ...
Think about this. Let's say I trust my friends (so when my friends sign John Doe is John Doe, it's really him). It's a big deal (not every friend is so security conscious, maybe he met this guy on facebook and looks so real), but would I trust someone because of a friends-friend's recommendation?
I know which friends are naive. But which friend's-friend's-friend is naive?
And those are the only web-of-trust connection I have with him? Can I trust him? Can I not? How do I tell?
It's of course up to you to decide who you can trust to certify other keys.
edit: It's worth mentioning, "owner trust" is strictly a local attribute -- just because you fully trust John, and I fully trust you, my trust for John's certification of 3rd party keys remains unknown.
A has friend 1 and 2. He vets them, checks their ID, goes to a key-signing party, trusts that they are 1 and 2 with his life.
Now he gets an email from "5000" who claims that he's from the IRS and needs to know information from you.
You look up this "5000"s signature.
Now, none of A's friends work in the IRS, but "5000" was signed by "500","302","201" and another 500 people.
"302" was signed by "23", "23" was signed by "2".
Should "A" send him the info?
Theoretically, he can call "2", ask him how "2" knows "23", then call "23" on behalf of "2", and so on.
But he doesn't know if "23" is honest, and all the more so "302".
And what if "302" says that he knows who he is because he self-identified as "5000 from the IRS" at a bar?
Too much thinking.
Now imagine A is the kind of person who downloads EXEs to view cat pictures?
In an ideal world you could query the mail server for the domain in question for the person's keys using a simple HTTPS transfer. Verify the certificate is signed by a trusted party and issued to the domain in question, then request the public key for your destination. Sign the mail with that public key, and probably store it (or a fingerprint) so you can note any anomalous changes later.
This could all be built into the mail client and happen at the click of a button. With an interface like this even your mother could use encrypted email.
But it can't happen because someone will point out that the web of trust can't be trusted because governments could infiltrate it. Perfect has been the enemy of good in this system for decades.
I was interested in crypto. Met theses guys that were hackers while I was a sysadmin specialized in SMTP(s).
And among the community of the dark warlords running openBSD (not a dev, just a user), I met this one guy explaining me correctly the whole ring of trust stuff. I incidently had read the howto, generated my fingerprint, and prepared myself for key signing.
And then, he proudly told me that he had his cats public key trusted by some others elite hackers. And it was true. I checked. And I threw away my fingerprints understanding it was human nature the problem, not the techno.
Before this day I had some doubt about the security experts, the balance being a tad on the pretty unsure they look like frauds. After this days the balance has been seriously going on the distrust side.
And more and more ever after.
I would accept he was not DJB and not a top one, but most of the community of security enthusiasts out of the coders and researchers look like football fanatics that are more interested in a posture or a status than anything else.
And to be honest I honestly like most technologies, PHP/js/Perl/Fortran/C/C++ included, but now it is the crowds around the technologies I have difficulty coping with. As much as I have no problem with sports, but I have problem with sports enthusiasts/fans.
And, again, as you mentioned, those were security experts.
You think that your neighbor won't fall for that?
Also for RSA it is using PKCS #1 1.5 and SHA-1 is used all over the place.
This is all not super serious, I wouldn't be too bothered about it. But it's not a solid crypto design by modern standards.
https://pdfs.semanticscholar.org/b6e2/3ac057b8716ebd4ab7831f...
They use Kesterel's Specware tools to essentially turn it from HOL properties to a formal design with code generation following. Kesterel was kind enough to open-source some of their stuff:
https://github.com/KestrelInstitute/Specware/
However, recent results in other tooling suggest the best way to go about it would be using tools like F* in miTLS, CRYPTOL, SPARK Ada, and/or Frama-C. Each component of a basic, subset of PGP has already been verified in isolation. Now, the algorithms just need to be fed into such tools, the protocol speced out miTLS-style, the integration proven sound, and object code shown to match the source. It looks doable with today's formal methods. More a matter of available labor and interest.