La majorité d'entre ceux m'ayant envoyé leur clé publique lors de leur lecture de l'article « Partie 4 : Générez et exportez vos clés GPG » m'ont en fait envoyé une clé avec un détail piquant : leur auto-signature n'est pas conforme.

Vous pouvez relire la première série ou les articles précédants si nécessaire :

L'auto-signature, c'est ce qui dit à gpg que cette clé vous appartient. Plutôt que de concevoir un truc tarabiscoté, gpg signe chaque clé publique avec sa propre clé privée.
Simple, donc efficace !

L'auto-signature est en effet très souvent générée avec l'algorithme SHA-1 alors qu'elle devrait l'être avec SHA-256 ou, top niveau 512.

C'est parce que votre configuration de gpg est en fait trop faible.

On va régler ça !

Le fichier de conf de gpg

Dans une distribution linux et sur Mac (normalement), votre fichier de configuration de gpg se trouve ici :

~/.gnupg/gpg.conf

Ce qui donne sous Linux:

/home/you/.gnupg/gpg.conf

Sous Mac OS X:

/Users/you/.gnupg/gpg.conf

Et sous Windows XP:

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

Je ne sais pas pour les versions suivantes de Windows.

Voici, en brut, le fichier de configuration de gpg tel qu'il est chez moi, avec mes commentaires en anglais. Pensez à personaliser pour correspondre à vos besoins, en particulier votre clé par défaut. Il est aussi disponible en téléchargement ici, signé avec ma clé personnelle, et la clé du tutoriel.

Il est très important que vous vérifiez la signature (au moins une des deux) de ce fichier. Si vous ne le faîtes pas, posez vous la question:

Pourquoi dois-je le faire, ou non ? Et pourquoi est-ce que je ne le fais pas ?

  • "La flemme" -> Pourquoi utilisez vous Gpg alors ? Pourquoi lisez-vous cet article ?
  • "Je ne vois pas l'intérêt !" -> Vous n'avez pas compris plusieurs éléments importants du tutoriel.
  • "Pardon, mais je vois toujours pas pourquoi ..." -> Quelqu'un pourrait avoir hacké mon site, ou votre connexion, ou que sais-je ... ?
  • "Je te fais confiance !" -> Merci. Je suis flatté. Mais l'argument du dessus reste valable. C'est aussi un bon entrainement.

Pour le dire crûment : un fichier aussi important que le gpg.conf (il contient les algorithmes à privilégier, les options de vérifications par défaut...) doit être distribué de manière sûre !

Bon, il vient ce fichier de 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

Si ce fichier n'existe pas (cela peut arriver sous MacOS notamment) alors il ne faut pas hésiter à le créer.

Comme je l'ai dis, votre clé a souvent une auto-signature faible. Facile de remédier à celà : dès que votre configuration de gpg correspond à votre envie, modifiez donc la date d'expiration de la clé.

D'une manière générale, si vous modifiez une des options de votre configuration, c'est une bonne idée de mettre à jour la date d'expiration de la clé.

La clé sera alors resignée. C'est bon ! Plus qu'à envoyer sur les serveurs de clés !