This page covers using GNU's Privacy Guard to sign and/or encrypt files or
emails.

====== Signing ======

==== ASC Signature ====
Signing text files and including the signature inline:
  gpg --clearsign testfile
creates testfile.asc:
<file>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bla blubb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDjiponMPprxY1hCcRAqwQAJ0TKJsjpIp7AHEguVtp/amMMaLCcwCfSeRz
/DcIOvltZ7M/azef+SiroAg=
=I+7W
-----END PGP SIGNATURE-----
</file>

==== SIG Signature ====
Having the signature in a separate file (use with e.g. binaries):
  gpg --sign --detach-sign testfile
creates a binary testfile.sig.

====== Signature Verification ======

Regardless of the type of signature, the following command suffices:
  gpg --verify filename
where ''filename'' is the file containing the signature, i.e. e.g.
//testfile.sig// or //testfile.asc//.
  sammy@uranos ~ $ gpg --verify zusammenfassung.txt.sig
  gpg: Signature made Mon Nov 28 11:28:20 2005 CET using DSA key ID FCDE6BBD
  gpg: Good signature from "Matthias G\xfc\x6etert <MatzeGuentert@gmx.de>"
  sammy@uranos ~ $ echo bla >> zusammenfassung.txt
  sammy@uranos ~ $ gpg --verify zusammenfassung.txt.sig
  gpg: Signature made Mon Nov 28 11:28:20 2005 CET using DSA key ID FCDE6BBD
  gpg: BAD signature from "Matthias G\xfc\x6etert <MatzeGuentert@gmx.de>" 

====== Encryption ======

  n0-1@Base test $ cat testfile
  bla bla blubb
  n0-1@Base test $ gpg --encrypt testfile
  n0-1@Base test $ cat testfile.gpg 
  …e}ÝNœúª€þ1 ǟ{Šw1Æ%XžâÒb:Â8Ô±ü@‘‚Û‘ƒ!±B¬‰Wª*Ól‡jŠS]B±ø
   
  [...]
   
  n0-1@Base test $ gpg --decrypt testfile.gpg 
  
  You need a passphrase to unlock the secret key for
  user: "Phil Sutter (eat THIS) <Phil@l3h.de>"
  1024-bit ELG-E key, ID 9CFAAA80, created 2005-03-23 (main key ID 16358427)
  
  gpg: encrypted with 1024-bit ELG-E key, ID 9CFAAA80, created 2005-03-23
        "Phil Sutter (eat THIS) <Phil@l3h.de>"
  bla bla blubb

====== GPG Agent ======

''gpg-agent'' provides the same funktionality for GPG keys as
[[SSH#ssh-agent|''ssh-agent'']] does for SSH keys.

===== Configuration =====

Startup can be done via ''.bash_profile'':
<file>
# start gpg-agent if not already running
if ! gpg-agent >/dev/null 2>&1 ; then
        eval "`gpg-agent --daemon --write-env-file $HOME/.gnupg/AGENT_VARS -s`"
elif [ -z "$GPG_AGENT_INFO" ]; then
        source $HOME/.gnupg/AGENT_VARS >/dev/null 2>&1
fi
</file>

To enable GnuPG to to use the agent, the following line has to be added to
//$HOME/.gnupg/gpg.conf//:
<file>
use-agent
</file>

====== PGP Keyserver ======

Keyservers manage distribution of public keys. The drawback of having the key
on the servers (they synchronise the keys between them) is an increased rate
of spam.

One can update his public keyring using the following command:
  gpg --refresh-keys
this should be done on a regular base, as the keys change from time to time
due to new subscriptions, etc.

====== GnuPG + Mutt ======

Mutt has built-in GnuPG integration. These are the necessary command
definitions (copied from the Gentoo default):
<file>
set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose --batch --output - %f"
set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f"
set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch --output - %f"
set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor \
 --detach-sign --textmode %?a?-u %a? %f"
set pgp_clearsign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor \
 --textmode --clearsign %?a?-u %a? %f"
set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt \
 --textmode --armor --always-trust --encrypt-to 0xC9C40C31 -- -r %r -- %f"
set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 --batch --quiet --no-verbose --textmode \
 --output - --encrypt --sign   %?a?-u %a? --armor --always-trust --encrypt-to 0xC9C40C31 -- -r %r -- %f"
set pgp_import_command="gpg --no-verbose --import -v %f"
set pgp_export_command="gpg --no-verbose --export --armor %r"
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r" 
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r" 
set pgp_autosign=yes
set pgp_sign_as=0xC9C40C31
set pgp_replyencrypt=yes
set pgp_timeout=1800
set pgp_good_sign="^gpg: Good signature from"
</file>

I use the following local options to configure GnuPG:
<file>
set crypt_use_gpgme=yes
set crypt_replysignencrypted=yes
set crypt_autosign=yes
set crypt_autoencrypt=yes
set pgp_sign_as="16358427"
set pgp_use_gpg_agent=yes
set pgp_auto_decode=yes
</file>

Another very helpful thing is to add one's own ID as hidden recipient. This
way encrypted emails are still readable for oneself and therefore can be saved
in the sent folder like unencrypted ones. Just add the following line to
//$HOME/.gnupg/gpg.conf//:
<file>
hidden-encrypt-to 16358427
</file>
(where ''16358427'' has to be replaced with the own key ID, of course.)

====== Key Expiry ======

When creating a GPG key, one has to specify either an expiry date, or disable
expiration. Expiring keys are helpful in case of a lost passphrase, i.e. when
it is not valid anymore and can't be revoked. So it will at least expire
somewhen. :)

This is how to edit an expired key and setting a new expiry date:
  % gpg --edit-key 16358427
  [...]
  Command> expire
  [...]
  Key is valid for? (0) 2y
  [...]
  Is this correct? (y/N) y
  [...]
  Command> key 1
  [... output with asterisk-marked encryption subkey ...]
  Command> expire
  [...]
  Key is valid for? (0) 2y
  [...]
  Is this correct? (y/N) y
  [...]
  Command> save
  % gpg --send-keys 16358427

====== Key Transitioning ======

From time to time it's advisable to replace one's own keypair by a new one, at
least that's the only way to update to a more secure algorithm or increase the
key size. The problem comes during the transitioning phase, where there is
plenty of data (emails for instance) which are still encrypted with the old
key's public part but the main key in use is already the new one. In order for
GnuPG to try the old one during decryption of this legacy data, the following
config setting comes in handy:

  try-secret-key <OLD_ID>

====== Links ======
http://codesorcery.net/mutt/mutt-gnupg-howto