> No one was sending you encrypted emails anyway
I actually use PGP for e-mailing quite often, for instance: how am I supposed to report security issues without gpg? (please don't suggest Whatsapp...)
I’ve never understood this obsession with using PGP to deliver security reports (even a lot of pen testing firms do it). We trust TLS to secure all sorts of remarkably sensitive data, why do we need to add an extra layer of encryption to security reports? It just seems like an unnecessary barrier to delivering the report to me, and the user experience is terrible. On top of that managing keys and ciphertexts is an unnecessary pain. Any time I see a public key that’s some org published years or even months ago, all I can think is that in the time since they generated that, they have absolutely had a number of people who had access to the private key resign.
To me, the only threat model where something like that makes sense, is if you think your critical service providers or the government is a threat actor, and in that case PGP probably isn’t going to be enough.
Interesting gray areas between easy determinations of whether or not something is centralized/decentralized or now.
As long as you're ok with relying on the keybase service being reachable and functional, trust is still decentralized and verifiable.
Also, I'm not sure how easy it is to run a private keybase PKI (anyone done this before?). For GPG/SKS keyservers, you can spin up separate pools of keyservers for private PKI pretty easily.
For the record there is a way to encode Keybase-like proofs in plain OpenPGP: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 for some reason Keybase decided to keep this validation centralized.
Essentially: a keyserver facility where you attest to your keys in public identities (like my hn profile), plus a bunch of end-to-end encrypted stuff built atop of it.
I still keep PGP/GnuPG keys up and working with email because it is universal and simple. The encrypted messages I have are easy to open and get on using a fresh machine/phone as long as I keep my key around. I don't depend on anyone to maintain their servers, etc. I'm still waiting for a modern replacement, but so far it hasn't happened for me.
I want to be able to encrypt/sign and have web of trust be a different issue.
You can go with somewhat centralized trust, but that only gets you do far. Or, rather, that forces everyone to deal with that centralized source. Much like the web of trust.
What situations are you encountering in 2019 where you really need a distributed web of trust?
That means that I'd be trusting GUANG DONG CERTIFICATE AUTHORITY and every other CA not to issue a fraudulent certificate against my domain. I don't think that's very secure.
In modern browsers, certificates are not trusted if they're not CT-logged, so it's impossible for a fraudulent one to exist without you knowing about it (unless it was issued before these requirements were put in place in ~April 2018, but once all of those have expired, it'll be a pretty solid system).
I can only think you're making a bunch of hidden assumptions about how trust works or why you would want to sign or encrypt data. Maybe you're thinking specifically about things like email, where web of trust might make more sense.
Consider, for example, if I'm doing backups and I just want to encrypt them for my eyes only. How could a web of trust even possibly make sense in that scenario?
I mean, yes. Pgp is a bad fit for that. So is tls.
Signing is for verification of identity over potentially compromisable channels. Not securing controlled items.
That is, why use a public key scheme, for private encryption? It is literally made to establish identity with someone else. Not yourself.
Even if you sign things for personal use, that is just to confirm nothing was tampered with. Which, if it was encrypted with a key, is already guaranteed. Otherwise it won't decrypt. Right?
Consider, you are still in the game I was talking about. Did they encrypt using a secret you know (your public key) or not. If not, it doesn't decrypt. If so, it does. But you still know nothing about who they are. At all. Just that whoever it was used your public key to encrypt.
Unless you are trust a signature they provide. Note, specifically not your public key, because again, either that worked to decrypt or it didn't.
So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient.
I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core part of any secure backup system.
You can verify backup integrity as long as you have the public key. This is useful for monitoring systems. You wouldn't want to stick your private key, unencrypted, on some monitoring system somewhere. Performing a backup requires the private key. That's the price.
Having built this system, I can say that much of what PGP does is saddle you with pointless keychain management on top of what is, conceptually, very simple. PGP authors are actively hostile to enabling people to do things like specify keys that aren't part of your keychain. That, and PGP comes with a bunch of configurable knobs and levers that only serve to sabotage any security that you might have in a more coherent system. It reminds me a lot of using the OpenSSL command-line tools, which everyone would hide behind scripts. Unfortunately, PGP is less scriptable than OpenSSL and you have to resort to wrapping PGP in higher-level language code like Python or Go just so you can extract the status output from a separate file descriptor, because GPG doesn't even have the basic courtesy of providing useful output in its output or status codes. (Look up the --status-fd option for GPG... it's necessary any time you want to do even the most basic operation with GPG.)
Then, if you have systems where you want to do automated backup, you can give them their own keypair. If they are individually compromised they can only compromise their own backups, going forwards.
> So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
I don't even remotely understand this argument. If you could spell out, from start to finish, why web of trust is necessary, then maybe I could understand what you are trying to say.
For this to work, you had to have a way to securely transmit your public key to the receiver and their public key to you. That is what the web of trust facilitates.
If you are in complete control of all locations, then you don't need to do the counter signing. Just indicate what key did the encryption on the other side. When you get it, either you can successfully decrypt, or you cannot. That is, never transmit your private key.
Now, you could self sign, I suppose. Such that you transmit another key to sign against to the remote. But what does that accomplish? If your backup system is compromised, they will have both keys on the remote. The one to encrypt, and the one to sign.
The reason I mentioned private encryption before is there is no need for authentication of data you created. Specifically the key. If you are the only one that knows the pair, then just make sure to keep one side secured. If you are worried it will ever get compromised, just make a new one every time.
What (I believe) klodolph is describing is that you can self-sign an encrypted backup and give it to an untrusted third party. When you later retrieve the backup you know that it had not been tampered by the untrusted third party.
In this case you have direct access to all private keys involved, so no web of trust is needed. In this scenario you trust a key only if you have created it yourself.
Edit: to elaborate. What is your threat model? If you are handing over encrypted data, when it is given back you are safe knowing it wasn't tampered. Either that, or the encryption scheme you used is broken.
If you are handing unencrypted data to someone else to encrypt using your public key, then you could use their public key to validate that they encrypted it. But you are, by definition, trusting that they did the encryption like you wanted them to.
Now, if you hand them a key to sign with and a key to encrypt with, you also have to give them the data to encrypt. In which case... why do you trust every link in the chain between you and them that it worked? The game is already over if they have your unencrypted data is in transit between you and someone else to start with.
For example, let's say you have a key (as an ordinary file) and a signed message in hand. How do you check that this key has signed this message, using the gpg command-line tools?
The problem with PGP is that it combines web of trust and the mechanical actions of signature verification and cryptography into one tool. It forces you to use one program both to express "trust" and to do signature verification. God forbid you should ever want to sign or encrypt something without futzing about with your keychain.
gpg2 --import pubkey.gpg
gpg2 --verify-files a-message.ascThe purported benefits of web of trust are completely irrelevant, the problem is that PGP handcuffs you to the web of trust and web of trust is often unwanted. You have to reduce and simplify your trust to something that PGP understands. There is no reason on this earth that signature verification should require importing shit into a database.
The whole philosophy of “do one thing well” would be nice here. PGP never lets you do one thing, it makes you buy the whole banana.
If you do not understand this your argument is moot.
It is not because you learned in class that pgp works with the web of trust that this is what actually happens in practice
As far as I know, OpenPGP's web of trust is not cryptographically broken: it is a bunch of public key signatures over other keys, and modern signing algorithms and hasing functions are supported and used. So I think that any tool that want to present itself as "GPG done better" should at least enable me to leverage the web of trust that is already in place. Otherwise, it might be a very nice tool, but for me is a very nice tool for doing something else.
People are quick to point to "modern" alternatives like Signal but they miss the web of trust which, correctly implemented would be a killer.