Most people who send me their public key while reading « Part 4 : Create and export your keys » actually sent me a key with a slightly wrong detail : the self-signature is not safe.

For a reminder, I suggest you read first serie. And you have the previous articles :

The self-signature is what tell to gpg that this key belong to you. Rather than having a complicated stuff, gpg signs each public key with its own private key. Simple and efficient !

The self-signature is often created with SHA-1 (the default gpg algo) whereas it ought to be with SHA-256 or 512.

This is actually because your gpg conf is weak.

Let's fix that !

The gpg configuration file

In a GNU/Linux distribution and under Mac (normally), your conf' file should be there:

~/.gnupg/gpg.conf

Thus, under Linux:

/home/you/.gnupg/gpg.conf

Under Mac OS X:

/Users/you/.gnupg/gpg.conf

And under Windows XP:

C:\Documents and Settings\<USER>\Application Data\GnuPG\gpg.conf

I don't know for other Windows releases.

You can read under my gpg.conf with comments. You have to personalize it (at least the default key). It is also available here to download, signed with my personal key and the tutorial key.

It is extremely important that you check this signature (at least one of those two). If you don't do it, ask yourself:

Why should I do it, or not ? Why do I don't ?

  • "I am lazy" -> Then, why do you use Gpg ? Why are you reading this article ?
  • "I don't understand why I should do it !" -> You have missed a few points of the whole tutorial.
  • "I still don't get the f..." -> One could have hacked my website, your computer, your connexion... ?
  • "I trust you !" -> Thanks. I feel flattered. But the argument above is still valid. It is good training.

To say it with bare words : a file so important as gpg.conf (containing algos, verifications options...) ought to be fetched in a safe and secure manner !

gpg.conf

## This has been inspired (but not only) by :
## https://raw.githubusercontent.com/ioerror/torbirdy/master/gpg.conf
## https://github.com/Mayeu/gpg.conf/blob/master/gpg.conf

# See the man page for a list of options.

# Uncomment the following option to get rid of the copyright notice

#no-greeting

# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.

default-key  20413A8E7F36CE55

# If you do not pass a recipient to gpg, it will ask for one.  Using
# this option you can encrypt to a default key.  Key validation will
# not be done in this case.  The second form uses the default key as
# default recipient.

#default-recipient some-user-id
#default-recipient-self

# By default GnuPG creates version 4 signatures for data files as
# specified by OpenPGP.  Some earlier (PGP 6, PGP 7) versions of PGP
# require the older version 3 signatures.  Setting this option forces
# GnuPG to create version 3 signatures.

#force-v3-sigs

# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you may want to use this option.

#no-escape-from-lines

# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification.  However for new
# installations it should be enabled.

require-cross-certification

# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set.  Please check the man page
# for supported character sets.  This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation.  Note that future version of GnuPG will change to UTF-8
# as default character set.

#charset utf-8
utf8-strings

# Group names may be defined like this:
#   group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678".  Note there is only one level of expansion - you
# cannot make an group that points to another group.  Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients.  In these cases it is better to use the key ID.

#group mynames = paige 0x12345678 joe patti

# Some old Windows platforms require 8.3 filenames.  If your system
# can handle long filenames, uncomment this.

#no-mangle-dos-filenames

# Lock the file only once for the lifetime of a process.  If you do
# not define this, the lock will be obtained and released every time
# it is needed - normally this is not needed.

#lock-once

# GnuPG can send and receive keys to and from a keyserver.  These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyservers:
#      hkp://keys.gnupg.net
#
# Example LDAP keyservers:
#      ldap://pgp.surfnet.nl:11370
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
#      hkp://keyserver.example.net:22742
#
# If you have problems connecting to a HKP server through a buggy http
# proxy, you can use keyserver option broken-http-proxy (see below),
# but first you should make sure that you have read the man page
# regarding proxies (keyserver option honor-http-proxy)
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other.  Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin.  hkp://keys.gnupg.net is an example of
# such a "server", which spreads the load over a number of physical
# servers.  To see the IP address of the server actually used, you may use
# the "--keyserver-options debug".

# To use the pool with tls, you have to download the CA file.
# I place it in the gnupg conf' dir'.It is explained on
# https://help.riseup.net/fr/security/message-security/openpgp/best-practices

keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/home/stephane/.gnupg/sks-keyservers.netCA.pem

# keyserver http://http-keys.gnupg.net
# keyserver mailto:pgp-public-keys@keys.nl.pgp.net

# keys.gnupg.net is also a good idea
# keyserver hkps://keys.gnupg.net

## Tor options. I have not mounted a local tor daemon, but it is a really good idea.

# keyserver-options http-proxy=socks5://TORIP:TORPORT
# keyserver hkp://qdigse2yzvuglcix.onion

# I do not like this option, but it seems a good one !
# It is explained on
# https://help.riseup.net/fr/security/message-security/openpgp/best-practices

keyserver-options no-honor-keyserver-url

keyserver-options auto-key-retrieve

# Common options for keyserver functions:
#
# include-disabled = when searching, include keys marked as "disabled"
#                    on the keyserver (not all keyservers support this).
#
# no-include-revoked = when searching, do not include keys marked as
#                      "revoked" on the keyserver.
#
# verbose = show more information as the keys are fetched.
#           Can be used more than once to increase the amount
#           of information shown.
#
# use-temp-files = use temporary files instead of a pipe to talk to the
#                  keyserver.  Some platforms (Win32 for one) always
#                  have this on.
#
# keep-temp-files = do not delete temporary files after using them
#                   (really only useful for debugging)
#
# honor-http-proxy = if the keyserver uses HTTP, honor the http_proxy
#                    environment variable
#
# broken-http-proxy = try to work around a buggy HTTP proxy
#
# auto-key-retrieve = automatically fetch keys as needed from the keyserver
#                     when verifying signatures or when importing keys that
#                     have been revoked by a revocation key that is not
#                     present on the keyring.
#
# no-include-attributes = do not include attribute IDs (aka "photo IDs")
#                         when sending keys to the keyserver.

# Uncomment this line to display photo user IDs in key listings and
# when a signature from a key with a photo is verified.

#show-photos

# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file is not deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input.  If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# The default program is "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"
# On Mac OS X and Windows, the default is to use your regular JPEG image
# viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
# photo-viewer "display -title 'KeyID 0x%k'"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"

# my signature par defaut: intermediaire
default-cert-level 2

## when multiple digests are supported by all recipients, choose the strongest one:
personal-digest-preferences SHA512 SHA384 SHA256 SHA224

# In this one, the trick is: should we use CAMELLIA ?
# It is actually a Japanese algo used by Japan and Europe.
# Not an USA stuff. I think this is a mark of safety in these times !
# It is also considered safe, and is younger than the others. So maybe better.
personal-cipher-preferences CAMELLIA256 CAMELLIA192
CAMELLIA128 TWOFISH AES256 AES192 AES 3DES

## preferences chosen for new keys should prioritize stronger algorithms:
default-preference-list SHA512 SHA384 SHA256 SHA224 CAMELLIA256 
CAMELLIA192 CAMELLIA128 TWOFISH AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed

## when making an OpenPGP certification, use a stronger digest than the default SHA1:
cert-digest-algo SHA512

## If you use a graphical environment
## (and even if you do not) you should be using an agent:
## (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64)
use-agent

## You should always know at a glance which User IDs gpg
# thinks are legitimately bound to the keys in your keyring:
verify-options show-uid-validity
list-options show-uid-validity

## Do not disclose the version
no-emit-version

## when outputting certificates, view user IDs distinctly from keys:
fixed-list-mode

## long keyids are more collision-resistant than short keyids
# (it is trivial to make a key with any desired short keyid)
keyid-format long
with-fingerprint

If this file doesn't exist, then you should bare create it.

As I said, your key has often a weak self-signature. Easy to cure : as soon as your configuration is good, modify your key expiration.

As a general rule, if you modify one of the options, it is a good idea to update your key expiry.

The key will then get self-signed again. You can then update it on the keys servers.