4 ms·

Maybe to ensure that it was you that created the backup? It may be nice when restoring the backup.

• taeric 8y ago
  But if you encrypted them, there is no reason to also sign them. Either you have the key to decrypt, thus you did it, or you don't, so you didn't. Signing is for verification of identity over potentially compromisable channels. Not securing controlled items.
  • afiori 8y ago
    if you encrypted it with a public key then you also need a signature, I am not sure what the parent meant though.
    • taeric 8y ago
      I'm not sure I follow. If you are decrypting with a key, either you trust it or you don't. It works or doesn't. 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?
      • Boulth 8y ago
        The point is anyone can encrypt to your public key, thus, anyone could create a "backup". They won't be able to decrypt it, only you, but still having a backup that you think was created by you but wasn't can be problematic.
        • taeric 8y ago
          Why would you be taking backups created by someone else, of your things? As soon as you've done that, you are already trusting that entity with your items before they did the backup. Would it matter what any metadata is? 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.
          • klodolph 8y ago
            Responding to the entire conversation here. 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.
            • taeric 8y ago
              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.