OpenPGP really works(foo.be)
foo.be
OpenPGP really works
https://www.foo.be/2016/12/OpenPGP-really-works
69 comments
It isn't because GnuPG doesn't work well or because it is too hard to use that people don't use it. They don't use it because other people don't use it.
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.
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.
>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.
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.
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.
> Had Diaspora been around before FB
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.
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.
I tend to agree. Naming is important and if you target masses (non-engineers, non-geeks etc.), you should name your product so that even a 5 years old kid would understand it without a second thought and memorize instantly. An anecdote, but I have harder times convincing people to use LibreOffice than OpenOffice for no reason other than a name.
> or XMPP been around before Skype
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, 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 :).
>> or XMPP been around before Skype
> 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
[3]http://lowendmac.com/pb/powerbook-190cs.html
[4]https://version6.ru/en/ipv6-for-freedom
> 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
[3]http://lowendmac.com/pb/powerbook-190cs.html
[4]https://version6.ru/en/ipv6-for-freedom
Sounds right, maybe Diaspora or XMPP would not become popular if they were advertised today. Software like VLC, Firefox, LibreOffice would because they're not communication platforms.
Chance might play a larger role than advertising in the early game, for communication platforms.
Chance might play a larger role than advertising in the early game, for communication platforms.
> 1. Facebook, Skype and WhatsApp solved problems others didn't and became big. Now it's too late to fight.
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.
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.
I just need to jump in here and harp on the thing that I'm sure regular readers of HN are sick of seeing me harp in on all the time. :P
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.
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.
I'm not sure that's the whole problem. The walled garden is a financial incentive for tech companies mainly, isn't it? It seems like it's going to a hard thing to shift; so far it's been a 'who cares' for most of us, but it's really going to start hitting once VR gets big, at least -- as far as I daydream about such things..
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..
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..
The thing is that the government is co-conspiring with the large companies to allow them to enforce their walled gardens through the wholly-artificial means of the CFAA, copyright, etc.
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.
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.
> It isn't because GnuPG doesn't work well or because it is too hard to use that people don't use it. They don't use it because other people don't use it.
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.
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 not convinced...
> 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.
> 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.
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.
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. ️
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. ️
PGP (now GnuPG) is used more these days than in BBS (Fidonet) years, particularly in the open source community. Software releases and packages in GNU/Linux distributions are signed by the developers. All the time. It happens automatically without end-user noticing. Is this not one definition of "working well?" Lot's of people are passively using it without knowing.
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.
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'd believe PGP is in wider use today than Fidonet is, but not much wider.
I have to laugh that Snapchat has apparently solved the identity exchange problem and PGP is still stuck with these ridiculously baroque implementations.
I have to laugh that Snapchat has apparently solved the identity exchange problem and PGP is still stuck with these ridiculously baroque implementations.
>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?
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?
The part where it works and millions of people use it.
>Signal isn't even that popular
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-...
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-...
I don't want to harp on about this again, but I really don't think you can put any sort of trust into such things as this. With GPG, you're producing an encrypted version of some text/data with a bit of code you can build yourself and run completely on your equipment, airgapped or whatever.
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..
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..
Complete protection from the NSA is not your typical user's need. Having your message opaque to bulk surveillance is about as good as a typical user can expect. If you are the explicit target of a state level actor, you're not going to win. If the Mossad wants to Mossad you, you're gonna get Mossaded.
> Complete protection from the NSA is not your typical user's need.
They do not know. But they must be educated because it is ethical.There is a extremly large difference between passiv listening and recording everything and cleverly hacking the Signal app, or even forcing OWS to do it for them. The cost differences alone are massive, not to mention that its harder to do while remaining hidden.
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.
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.
I sign almost all outgoing mail, hoping someone will notice. In three years I've got one question about it. Some people complain they can't open the attachment, as I use PGP/MIME to keep the message readable.
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.
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.
> 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 :)
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 :)
If ever there were a user group that should have forced pgp adoption, it is lawyers. When I worked at a big law firm, I lobbied for it and ran into a bunch of IT managers who had never heard of anything unless Microsoft sold it to them.
> 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.
End-to-end [1] is using OpenPGP.
[1]: https://github.com/google/end-to-end/
End-to-end [1] is using OpenPGP.
[1]: https://github.com/google/end-to-end/
It is surprisingly easy to use PGP/GnuPG. Check this tutorial https://emailselfdefense.fsf.org/en/.
It is _just_ slightly more complex than using Twitter once configured.
It is _just_ slightly more complex than using Twitter once configured.
No, even this step-by-step tutorial is not easy for "normal" user. It's plagued with obscure terms and concepts (keypair, keyserver, public key, web of trust, revocation certificate etc.). Sure, for us, developers/engineers/geeks, it looks trivial, but try to send this link to your grandma and see how it goes.
It's the configuration that kills it, and a large part of that is loading context into the user's mind (the highest drop-out form).
I see more and more comparisons between Signal and OpenPGP.
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).
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).
This applies to much of the XMPP discussion above, too. Also worth noting that GnuPG isn't even what you send the emails with. And that PGP on mobile is almost unheard of. I doubt I could explain how to send an PGP encrypted email (for example, to a doctor/lawyer/accountant) inside of 2 minutes.
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.
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.
Interesting that Moxie wishes PGP were dead (inline with his views in the LibreSignal/Websocked/Gapps PR).
https://moxie.org/blog/gpg-and-me/
https://moxie.org/blog/gpg-and-me/
I have been using OpenPGP for years without problems. Key transition / exchange / verification can be a bit painful, but actually it is not that hard.
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.
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.
> 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.
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.
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.
What would you consider a sane key rotation cycle? 1 Month? 1 year, 2 years, 4 years?
How do you feel about Yubikey-based keys? Asking for a friend...
I have a YubiKey myself and they're really convenient. There's a cryptoprocessor inside so the key doesn't have to leave the device. I think it's more secure than a regular computer connected to the internet.
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
² http://security.stackexchange.com/a/31598/9252
³ http://www.jabberwocky.com/software/paperkey/
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
² http://security.stackexchange.com/a/31598/9252
³ http://www.jabberwocky.com/software/paperkey/
Most workflows utilizing OpenPGP cards (like the Yubikey) encourage better key hygiene. Generally you'd create a certification key which lives offline 100% of the time, with a subkey issued to the Yubikey. This means your offline key can persist for a very long time while you can safely rotate the day to day subkey.
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.
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.
You gloss over the key management, but it is the primary failing of PGP (and GPG). The lack of built-in key management means it is only half of the solution, and the community has never managed to coalesce around a single sane solution. Instead we have people trading paper notes or using grotty services with custom protocols and if you just want to send an encrypted email to somebody there's no standard way to look up their key.
I have yet to find an email client that will even do the simple search of the keystores for you. It's maddening.
I have yet to find an email client that will even do the simple search of the keystores for you. It's maddening.
As a sort of basically reliable swiss army knife for file-based encryption problems, the kinds of problems you'd otherwise use AES passphrase-encrypted ZIP files to solve, PGP not only works but also has a bad rap.
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.
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.
> AES passphrase-encrypted ZIP files
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.
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.
A little off topic but could you point me towards some resources for learning about what pgp was meant to solve? I've read back and forth opinions about it on hackernews,reddit, etc but I've not seen a definitive description of how it attempts to solve the problem of encrypted communication that wasn't heavily editorialized.
A lay nutshell summary: there is one giant problem in crypto systems since the dawn of time; how to distribute the keys to locked documents/files and keep those keys out of the "wrong hands". For the majority of history of cryptology, the only option was symmetric keys (the same key is used to lock the document as to unlock it). This is conceptually simple (she who has the key has the access), but at the cost of making distributing these keys a giant challenge of secrecy (anyone can intercept that key in transit and use it to unlock documents; worse, someone can intercept that key and the people who are supposed to use the key might not even be aware someone could be snooping).
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.)
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.)
> > As a sort of basically reliable swiss army knife for file-based encryption problems, the kinds of problems you'd otherwise use AES passphrase-encrypted ZIP files to solve, PGP not only works but also has a bad rap.
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.
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.
Who said anything about sending the file anywhere?
Secure communication with PGP is a pain.
https://gist.github.com/grugq/03167bed45e774551155
https://gist.github.com/grugq/03167bed45e774551155
Yes, this. But remember: a lot of this is about electronic mail, not PGP in particular.
These links might be interesting to you: http://www.pgpi.org/doc/
If you just want to encrypt a file, scrypt works well for this purpose.
I didn't know Colin also wrote an encryption utility that uses the scrypt KDF. It does seem better than using GPG to password encrypt files.
Could you give an example of "problems you'd otherwise use AES passphrase-encrypted ZIP files to solve"? Do any of them involve sending the data anywhere (i.e., the sender and receiver are the same person)?
I think my question is now answered by https://news.ycombinator.com/item?id=13383171, in particular https://news.ycombinator.com/item?id=13383211.
[deleted]
No one criticizes openPGP on the crypto point of view.
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.
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.
> No one criticizes openPGP on the crypto point of view.
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
- ...
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
- ...
Would the lack of perfect forward secrecy be considered a shortcoming?
The crypto in OpenPGP is actually far from ideal. They combine some arcane block cipher mode with something called mdc ("modification detection code"), which isn't a proper authentication. It's kinda surprising that this hasn't caused more issues (though there were some authentication stripping attacks). It should switch to a proper AEAD mode.
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.
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.
Web of Trust seems to be an inherently broken paradigm.
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?
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?
PGP already allows for this via "owner trust". When you sign a key, also indicate the level of trust you have in newly certified key's owner to certify other keys.
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.
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.
I lost trust in the user's of PGP in 2000 at the Free Software Meeting.
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.
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.
I have no problems with that guy. I have problems with all those guys who signed the key.
And, again, as you mentioned, those were security experts.
You think that your neighbor won't fall for that?
And, again, as you mentioned, those were security experts.
You think that your neighbor won't fall for that?
So let's go through a hypothetical situation:
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?
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?
At this point we should really be leveraging the (admittedly problematic at times) chain of trust built for the web.
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.
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.
online and offline are both important. Is pgp implemented on any formally verified code base?
No. I've only seen two, formal verifications of secure email with neither being PGP. I can't find the link to one but the other of Privacy-Enhanced Mail is here:
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.
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.
My mobile Chrome is complaining about the site's certificate. Does this happen for others too? It seems it is having an issue with the issuer which is Let's Encrypt. Really strange.
It doesn't
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.