Return to Answer

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!

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. It sounds like you're using the wrong GPG 'trust model' to me.

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.

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.

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 public after all) 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.

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. It sounds like you're using the wrong GPG 'trust model' to me.

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.