WireGuard signale une longueur de clé privée incorrecte : que faire ?

Le message indique que la clé privée a une longueur incorrecte, et cette formulation renvoie d’abord à l’encodage, ensuite à la cryptographie. Les clés WireGuard encodent 32 octets en base64, ce qui donne 44 caractères avec le remplissage final, donc une valeur d’une autre taille n’est pas une clé, aussi aléatoire paraisse-t-elle. Compléter la chaîne jusqu’à ce que l’analyseur l’accepte produit une valeur bien formée qu’aucun pair ne reconnaîtra jamais.

Deux tâches différentes se cachent derrière cette erreur : réparer le texte d’une clé valide, et remplacer une identité que vous ne détenez plus. Elles ont des conséquences différentes, et l’une d’elles invalide l’autre extrémité.

Ce que l’analyseur attend

Une clé WireGuard, c’est 32 octets de matériel de clé en base64 avec remplissage standard, ce qui donne une chaîne fixe de 44 caractères. Les outils rejettent tout ce qui ne se décode pas exactement sur 32 octets, car la courbe sous-jacente prend un scalaire de 32 octets et rien d’autre. Les valeurs publiques et privées utilisent le même encodage, si bien que l’analyseur ne peut pas savoir, à partir du seul format, laquelle des deux vous avez collée. Cette ambiguïté est à l’origine de la moitié de la confusion autour de cette erreur.

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

Si votre valeur se décode sur 32 octets, la longueur est correcte et la plainte vient d’ailleurs dans le fichier. Si elle se décode sur quelque chose de plus court, vous avez du matériel tronqué et non un problème de formatage.

Dommage de formatage ou mauvais matériel ?

Les dommages de formatage se concentrent sur les bords : guillemets ajoutés par un shell, étiquette comme private_key copiée avec la valeur, saut de ligne inséré par un client de messagerie, ou espace final qui a survécu au collage. Chacun de ces ajouts modifie la chaîne sans changer les octets, donc les retirer restaure l’identité d’origine. Comparez le fichier au registre de provisionnement caractère par caractère au lieu de supprimer la ponctuation jusqu’à ce que l’analyseur se taise.

Un mauvais matériel, c’est autre chose. Un mot de passe, une clé de certificat ou une valeur publique peuvent tous sembler plausibles et se décoder sur la mauvaise taille. Aucun nettoyage ne les transforme en le scalaire attendu par le pair. Ce cas demande une nouvelle identité, pas une correction.

Une clé publique dans le champ privé

La confusion la plus courante est une valeur publique collée dans le champ privé, ou l’inverse. Les deux sont du base64 valide de 32 octets, donc le contrôle de longueur passe et la poignée de main échoue plus tard sans message utile. Une clé privée est le scalaire qui produit la publique, vous pouvez donc trancher en dérivant la valeur publique et en la comparant à ce que le pair autorise. Quand la valeur dérivée ne correspond pas au registre, vous tenez la mauvaise identité et non une faute de frappe.

Remplacer la clé privée du client sans mettre à jour la clé publique autorisée à l’autre extrémité recrée le même décalage, avec la confusion supplémentaire que le fichier du client semble désormais cohérent avec lui-même. Changez les deux extrémités en une seule opération, sinon la personne suivante déboguera la mauvaise moitié.

Réparez le profil, puis prouvez la poignée de main

Une fois que la clé se décode à la bonne taille et correspond au couple autorisé, il reste le profil et la route. Les commandes ci-dessous génèrent un couple neuf quand c’est nécessaire, vérifient la taille décodée d’une clé existante et lisent la valeur publique que l’interface utilise réellement. Ne collez jamais une valeur privée dans un ticket ou sur un site de décodage.

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

Le contrôle de taille répond à la question de savoir si le matériel a la forme d’une clé, et la requête de route à celle de savoir si un paquet atteindrait un jour l’interface. Une ligne de poignée de main qui reste vide alors que les deux contrôles passent déplace le diagnostic vers le point de terminaison du pair et les adresses autorisées. Relisez la clé publique de l’interface face au registre de provisionnement une dernière fois, car un profil enregistré obsolète peut sembler correct alors que l’actif diffère].

Notez quelle valeur vous avez remplacée et où se trouve la copie autorisée. La prochaine personne qui touchera ce pair doit savoir quelle extrémité a changé.