The deepest I ever got into active PGP/GPG was in college (where it is certainly easiest to have WoT key signing parties) and so far as I recall none of us ever really bothered encrypting anything to each other, we just signed a most of our emails as something of a prideful badge that didn't really mean much all things told. (To the point where at least one friend made a joke fake PGP signature that wouldn't verify to just prove no one was bothering to verify them either.)
I did exactly the same, signature as a badge of being one of "those guys". In the days of 56 bit "international edition" Netscape (or slightly thereafter, but still heavily influenced by that early wave of NSA-awareness), it felt like being way ahead of the curve. Kudos to the guy with the fake signature, in hindsight I must say that he truly nailed it.
One day however, my bank started offering transaction notifications by email, with optional PGP encryption. Suddenly there was real utility, and without any trace of WoT issues (key exchange over the same web frontend already trusted for actually transferring money, and the key in question is only for read-only messages). Other than that, the only encrypted messages I receive are the ones I send to myself as a convenient (because everything is already set up) form of secure cloud storage.
This has been my experience. The only "good" experience I've had with encrypted messages through email was a back and forth exchange I had with a fellow Keybase user where I manually copy and pasted blocks of encrypted text into/out of their web interface.
From my experience - the only PGP users I've spoken to were all on Keybase or interested in a Keybase invite. It was about 6 people for the entirety of last year - and 3 people this year...it certainly has a problem of "almost nobody uses it" but Keybase seems to have eased things slightly - or at least made it easier to discover people who also use PGP.
I see the two problems being "People don't bother with the clunkiness of using PGP when sending an email about what to pick up from the store" and "most users have no reason to talk to most other users".
I'm considering making it a point to message people with interesting Keybase avatars or social profiles tied to their Keybase if only to have an excuse to use PGP more, as silly as that might sound.
I have a keybase account and don't really use it. I like the idea, but part of the issue for me is attaching my "real name" to various online identities. I've used different types of pseudonyms over the years and do to poor opsec, some of them could be linked to me using the pseudonyms I use now. It's nothing illegal, but also nothing I'd like others to know about. So to attach my real name to keybase, I'd have to reestablish my identity in various places. Doing that, of course, removes some of the trust associated with the keybase model.
Additionally, and I realize this is tangential to this discussion, I use pseudonyms to somewhat reduce my privacy "surface", so to speak. If I take my twitter, HN, reddit, etc, etc. and say "this is me", you could build a pretty decent profile of who I am (politics, hobbies, profession, where I live and so on). That's a different privacy problem than keybase is trying to solve, so no criticism is intended, but it is a problem for me.
I believe one of the creators had said it is okay to have multiple accounts to keep identities separate or even to have an account for each identity. It does make it far less user friendly to need multiple accounts and multiple keys though and introduces a larger chance of making mistakes. Especially if it isn't that important to you (and it doesn't need to be!)
I use KB as an easy way for people to verify my signed messages - not necessarily for sending encrypted messages to other users. Mostly just a "This is me, you can verify it is me at Keybase easily - as long as you trust Keybase."
Doing that means users don't need to install PGP and know how to use it to verify that I am me. It isn't important now - or hopefully ever. By making a practice of it, my users expect it. if I am ever compromised, the malicious actor won't succeed in fooling my users as I expect at least a few will try and verify the message and will see it doesn't verify.
For myself, it's about being a solution for a "what if?" scenario than anything practical or even privacy-related. It's just the best psuedonymous way of proving identity within some level of reasonable doubt that I know of.
Keybase has clearly moved away from PGP. They want to use Saltpack whenever possible, NaCl based encryption. They want to solve the problem of multiple devices and not having to share the private key between all of them.
As far as I know they are working on a messaging app as well.
I admit my ignorance of saltpack and keybase's implementation of it, but don't they propose storing the key for you? That seems to create a trust issue, which is precisely what the author is complaining people don't pay attention to, trust.
On the other hand, perhaps the argument for this would be a "trusted 3rd party" model (a la S/MIME).
That's an interesting solution. Rather than having keybase keep your key, your devices are communicating directly to validate each other? I'm going to have to review this in more detail, thanks.
I don't think they are working on other problems, rather they realised that GPG has limitations and they can not solve it with PGP. The problem they are working on, is the same problem they started with.
Stuff to secure has moved away from email while gpg stays primarily an email project.
The concept of a git repo means I don't need to sign anything, I'll just roll back if I pull the wrong thing. Socialization at work hasn't atomized enough that my only human contact with a coworker would be a gpg signed commit anyway.
The concept of software distribution being a tar.gz.gpg or verifiable md5 file is obsolete. Behind the scenes something like apt-get does sign things but how to integrate its list of keys with the end user is a mystery, its essentially magic. Besides it provides no security due to lack of MITM attacks in practice.
Can't use weak OS unless its behind a firewall and/or accessed thru the VPN at which case plain text is about as strong as the weak OS and the VPN or physical LAN security is "good enough". So plain text files on a networked fileserver perhaps relying on login and permissions but mostly on audits and fire anyone who does something naughty.
Everyone needs version control no one understands it but some (repeat, some) devs. The office workers have a similar relationship with encryption. Also with databases, given that the corporate standard database is Excel. Talk till you're blue in the face, it will change nothing. Good idea, not good here. If you think office workers need encryption, you're probably wrong, but it doesn't matter because they definitely won't listen anyway. They're too busy making closed siloed databases with Excel.
Can't use GPG to encrypt web traffic, there's a whole SSL https infrastructure for that. The cloud resource can be assumed to be completely government(s) (and hacker) penetrated at all times. Just a business decision to tolerate that. I could use encryption and signing to make sure the traffic isn't interfered with before the NSA logs their plain text version for all time, but why make their jobs easier?
Theft by monitoring data streaming along has pragmatically never been an issue, its always someone stealing entire (copied) mass storage units at a time or violating some higher level business protocol of "look don't touch" or even "don't touch" but its all plain text for various business reasons. So encrypting transmissions is a waste of time, VPN exists more for AAA not to prevent monitoring. Multiple governments and corporations have full access to both endpoints anyway.
Email is mostly (exclusively?) used for public mailing lists, and corporate receipt/alert traffic, none of which is benefited by encryption. Its been awhile since I had an old fashioned email conversation on email. Everyone loves texting and messaging none of which can use encryption usefully.
Anyone with physical access to the device can pown it completely, theres no point in a purely software solution you're just wasting time.
Very few people had an application in business or real life in say 1970 for nuclear grade encryption. Nothing has changed to 2017 other than its trivial to provide if someone needs it. Many people want it because its cool but it does nothing useful for them so its definitely a want not need.
> The concept of software distribution being a tar.gz.gpg or verifiable md5 file is obsolete. Behind the scenes something like apt-get does sign things but how to integrate its list of keys with the end user is a mystery, its essentially magic. Besides it provides no security due to lack of MITM attacks in practice.
The very first bootstrap is impossible to do securely in the general case short of building a computer from scratch, but you can do things that make it difficult to attack e.g. ask a bunch of different friends what the sha1sum of the latest debian release should be.
On the assumption that you manage to get a non-compromised version of debian installed you are secure even against MitM attacks; there's a chain of trust, every package has been signed by a key that has a key fingerprint claimed by a specific human maintainer, and new maintainers can only join after at least one maintainer has confirmed their identity against a government-issue document. Of course this doesn't make attacks impossible (e.g. rubber-hoses against one of the maintainers), but it makes the cost a lot higher.
Yeah. I fear the open-source side only ever catches up once something becomes commoditized, so the actual answer is probably that if you care enough you use a weird and slow phone built for this stuff (that Mozilla phone project?), you use whatever the current replacement ROM project is (I would hope one of Cyanogen et al would offer a carefully signed open-source build - I haven't actually looked), or you wait a few years.
Even if cyanogen was perfect, there's a closed source firmware running baseband processor with complete access to system memory, microphone, gps, and the network.
