Mise à jour de clé PGP

Palaiseau, le 2 juillet 2020

Cher Journal,

Ma clé PGP 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D est un peu faiblarde. C'est une clé de type rsa/3072. Or la taille recommandée, du moins pour travailler avec le projet Debian, est d'utiliser une clé de type rsa/4096. Le choix d'utiliser une clé de 3072 bits ne venait pas vraiment de moi, mais plutôt de la valeur par défaut fournie par le logiciel GPG, désormais implémentation la plus commune de PGP. Cette valeur par défaut est toujours d'actualité, donc il est préférable, en créant une nouvelle clé, d'utiliser l'option --full-gen-key afin de pouvoir spécifier la construction d'une clé de type rsa/4096.

Il n'est pas possible d'augmenter la taille d'une clé existante, il faut en crééer une nouvelle. Heureusement, il y a des procédures pour faciliter la migration. Le site du trousseau de clé de Debian suggère d'utiliser l'ancienne clé pour certifier la nouvelle clé, lorsqu'il est question de mettre à jour une clé afin d'en renforcer la sécurité.

La première étape est donc de lancer la construction de la nouvelle clé, en pensant bien à préciser la configuration qui va bien, notamment au niveau du type et de la taille de la clé :

$ gpg --full-gen-key
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
  (14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits

Les clés devraient toujours avoir une date d'expiration dans un avenir proche. Je repousse en général l'échéance à peu près une fois tous les 14 mars, le jour de π, mais une clé ne devrait en général pas être valable plus d'un an :

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 1y

Key expires at Thu Jul  1 00:55:17 2021 CEST
Is this correct? (y/N) y

Arrivé à ce point, le plus dur est passé, il ne reste qu'à indiquer le nom et le courriel en vigueur. Le commentaire devrait rester vide, car son contenu serait rendu public et il n'existe pas vraiment d'information standard pour son remplissage :

GnuPG needs to construct a user ID to identify your key.

Real name: Étienne Mollier
Email address: etienne.mollier@mailoo.org
Comment:
You are using the 'utf-8' character set.
You selected this USER-ID:
    "Étienne Mollier <etienne.mollier@mailoo.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

La clé est enfin construite, avec la bonne taille, et une date d'expiration, qui pourra être repoussée un peu plus tard dans l'année en utilisant l'option --quick-set-expire de GPG par exemple. Les copies d'écran ci-dessus ne correspondent pas tout à fait à la session pendant laquelle j'ai construit ma nouvelle clé 8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA, mais pour la démonstration, ça fera l'affaire.

Pour que la nouvelle clé hérite du la réputation de l'ancienne, il est possible de la signer :

gpg --sign-key '8F91 B227 C7D6 F2B1 948C  8236 793C F67E 8F0D 11DA'

Attention : il ne faut pas signer la nouvelle clé avec l'ancienne si l'ancienne est compromise. Si une clé est compromise, le premier réflexe à avoir est de la révoquer, en poussant le certificat de révocation sur les serveurs de clés.

Enfin, pour que les petits camarades puissent profiter de la nouvelle clé avec la notoriété de l'ancienne, les deux clés doivent être poussées sur les serveurs de clé :

gpg --keyserver keys.gnupg.net --send-keys \
	'8F91 B227 C7D6 F2B1 948C  8236 793C F67E 8F0D 11DA' \
	'5AB1 4EDF 63BB CCFF 8B54  2FA9 59DA 56FE FFF3 882D'

Je précise le serveur de clé, car par défaut, je n'utilise pas les serveurs SKS, mais le serveur Hagrid, qui a été déployé suite à l'exploitation de vulnérabilités dans le protocole vieillissant des serveurs SKS l'année dernière :

gpg --keyserver keys.openpgp.org --send-keys \
	'8F91 B227 C7D6 F2B1 948C  8236 793C F67E 8F0D 11DA' \
	'5AB1 4EDF 63BB CCFF 8B54  2FA9 59DA 56FE FFF3 882D'
[ICO]NameLast modifiedSize
[PARENTDIR]Parent Directory  -

  —