What trust level should I give keys I need for encryption?

Question

As I'm encrypting server backups, I typically install my public GPG key from a keyserver into me server's keyring:

gpg --search-keys 6569758F

I import the key into my keyring.

I then attempt to encrypt a file:

gpg --encrypt --recipient 6569758F myfile.log

I'm now presented with something like this:

gpg: EE928AAF: There is no assurance this key belongs to the named user

pub  4096R/EE928AAF 2013-12-05 Naftuli Tzvi Kay <[email protected]>
 Primary key fingerprint: 0E26 BDF1 BD1C 4A16 9571  21A8 8938 1D75 6569 758F
      Subkey fingerprint: 65F4 87F2 C898 F0E7 0377  EBA1 8484 EC48 EE92 8AAF

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 

I now need to 'trust' the key. However, I've found that unless I trust the key "ultimately," ie: level 5, I get this prompt every time I need to encrypt something, which doesn't work too well for shell scripts.

Do I really need to trust a key ultimately to simply encrypt files with it?

Answer 1

The title of the post and the actual question you're asking don't quite match. If I'm reading this right you're asking how best to use your own public PGP key to encrypt backups. On the other hand the title of the question is getting at assigning trust levels to keys for encryption. Sounds to me like you're using your own key for the encryption so assigning it a level of trust isn't what you're looking for. IMHO you're using the wrong GPG 'trust model' for the the backup problem.

You can explicitly bypass all key validation in GPG by changing the 'trust model' for the command you're executing. By default the 'PGP' trust model is used which is why GPG expects you to explicitly mark keys as trusted. Alternatively you can tell GPG to use the 'always' trust model which will bypass the message you're seeing:

--trust-model always

I think this will get you the behavior you're after. Keep in mind though, your script is downloading a key from a remote host that you don't control so you don't really have any guarantee that it's the key you're expecting (key server compromise). If you're only expecting to use the one key to encrypt your backups it may be sufficient to simply embed the public key in your script (it's not sensitive) and cut the keyserver out of the architecture completely. This will remove all reliance on the keyserver and simplify the trust relationships in your backup solution.

Just a though. Hope this helps.

As requested here's an example. Let's assume I want to collect backup data on a system that I admin. I only want this backup data to be recoverable by myself. To achieve this I want all data collected in the script to be encrypted with my public PGP key. I'm also assuming that the user account doing the backup isn't used for anything beyond backups so there's nothing important in the ~/.gnupg directory and that I can delete it without worrying about lost keys.

ALWAYS BACKUP your .gnupg directory before playing around with this!

The following is a simple bash script that will encrypt some text with a public key that's embedded in the script:

#!/bin/bash -e                                                                 

gpg --trust-model always --import <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

xxxxxx
...
...
-----END PGP PUBLIC KEY BLOCK-----
EOF

echo "backup data" | gpg --trust-model always --armor  --encrypt --recipient [email protected] > backup-data.enc

The 'magic' in this script is the use of the shell 'Here Document' (see the EOF markers) to embed my public key in the script while passing it to gpg over stdin to import my key before doing the encryption / backup task. Naturally you'll have to put all of your ASCII armored public key in place of the '...'s in my example. Also be sure to replace '[email protected]' with the ID associated with your public key. Typically this is your email.

There's a million ways to clean this example up and make it more useful. Importing the public key on each run is a bit ridiculous so checking to see if the key is already in the ring is where I'd start :)

Good luck!

Answer 2

When putting ultimate trust on a key, you're defining it as your own one.

Trust enables a valid key to be considered when calculating validity of other keys. For being valid, you need to have a trust path to this key, which is realized by signing it (or have path of signatures from key to key to it, all being trusted).

This is rather confusing in the beginning, especially because the terms seem mixed up. I explained the web of trust in more details in this answer.

If you know who the key owner is and checked this, you could just sign the key (and maybe even send it to a keyserver). If you're not too sure, you could perform a local signature (which will never be uploaded/exported) using your own key. Both will make sure the key is valid, you do not need to trust it!