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.
Basically, what you are describing sounds somewhat nonsensical. When you encrypt and sign data to be transmitted to someone else, 4 keys are involved. You encrypt with the receivers public key so that they can decrypt using their private key. Then, you sign with your private so that they can verify it was you with your public.
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.
The system performing the backup and the system storing the backups can (and often should) be in different locations.
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.
You still don't need to sign in that case. Either it wasn't tampered with and still decrypts, or it was tempered with, and no longer decrypts.
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.
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.