Clés Nostr expliquées : votre identité numérique en deux chaînes

Votre compte Nostr n'est pas une combinaison nom d'utilisateur et mot de passe. C'est une paire de clés cryptographiques, l'une publique et l'autre privée, que vous gardez vous-même. Chaque message que vous publiez est signé avec la clé privée ; chaque client qui voit votre message vérifie la signature par rapport à votre clé publique.

C'est la chose la plus importante à comprendre à propos de Nostr, car elle façonne tout le reste. Votre identité ne peut pas être récupérée si vous la perdez, car aucune entreprise n'en a jamais eu de copie. Votre compte ne peut pas être banni par une plateforme, car il n'y a pas de base de données de plateforme d'où le retirer. Ce sont les mêmes propriétés vues sous des angles différents.

Ce guide explique ce que sont les clés, ce que chacune fait, comment elles sont codées, et les erreurs spécifiques qui les perdent.

TL;DR. Votre npub1... est votre clé publique. Sûr de partager partout. Votre nsec1... est votre clé privée. Gardez-la dans un gestionnaire de mots de passe ou un morceau de papier imprimé dans un endroit sûr. Ne la collez jamais dans un formulaire de site web. Perdez-la et l'identité est définitivement perdue.

Quand vous êtes prêt, prenez votre adresse @nostr.blog →

Ce qu'une paire de clés est réellement

Une paire de clés est deux nombres mathématiquement liés. Les mathématiques utilisent la cryptographie sur courbe elliptique sur une courbe appelée secp256k1 (la même courbe que Bitcoin utilise).

• La clé privée est un nombre aléatoire de 32 octets. N'importe quel nombre aléatoire de 256 bits fonctionne ; il n'y a rien de spécial à propos de la vôtre.
• La clé publique est dérivée de la clé privée par un calcul spécifique sur la courbe elliptique. Étant donné la clé privée, calculer la clé publique est rapide. Étant donné la clé publique, recalculer la clé privée est supposée être pratiquement impossible.

« Pratiquement impossible » signifie ici : aucun algorithme connu ne peut le faire en un temps raisonnable sur un ordinateur qui existe ou qui plausiblement existera. La sécurité repose sur cette asymétrie. Vous publiez la clé publique librement ; vous gardez la clé privée absolument.

Ce que chaque clé fait

La clé publique est votre identité. Quand quelqu'un vous suit, il suit la clé publique. Quand quelqu'un vous mentionne, il étiquette la clé publique. Quand un relay stocke vos messages, il les indexe par clé publique. Tout ce qui est visible à propos de vous sur le réseau est attaché à cette seule valeur.

La clé privée signe. Chaque événement (message, réaction, mise à jour de la liste de suivi, changement de profil) porte une signature de Schnorr produite à partir du hachage de l'événement et de la clé privée. N'importe quel client peut exécuter la vérification inverse : étant donné la clé publique, le hachage et la signature, vérifier que seul le détenteur de la clé privée correspondante aurait pu produire cette signature.

Le résultat : les relays et les clients n'ont pas à faire confiance à quiconque. Ils vérifient les signatures eux-mêmes. Un message falsifié avec une signature invalide est silencieusement rejeté. Un vrai message signé par la bonne clé est accepté peu importe quel relay l'a servi.

Comment les clés sont codées

Un nombre brut de 32 octets est peu pratique à regarder ou à taper. Nostr utilise deux conventions de codage.

Hexadécimal. Les octets bruts écrits en hexadécimal minuscule : 64 caractères, a-f et 0-9. C'est la forme canonique qui apparaît dans les fichiers JSON NIP-05 et la plupart des détails du protocole.

Exemple de clé publique en hexadécimal : 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Les mêmes octets enveloppés dans un format orienté vers l'humain avec un préfixe et une somme de contrôle. Le préfixe dit aux humains (et aux logiciels) de quel type de chose il s'agit. npub1 signifie « c'est une clé publique Nostr ». nsec1 signifie « c'est une clé privée Nostr ».

Exemple de clé publique en Bech32 : npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

La somme de contrôle en Bech32 est importante. Si vous changez accidentellement un caractère, la somme de contrôle échoue et n'importe quel outil rejette la clé comme invalide. Cela évite la corruption silencieuse pendant le copier-coller. L'hexadécimal n'a pas cette sécurité ; un seul mauvais caractère dans une clé hexadécimale produira une identité différente (mais valide en apparence).

Des préfixes existent pour d'autres types de données Nostr aussi. note1 est un ID d'événement. nprofile1 est une clé publique groupée avec les relays recommandés. nevent1 est un ID d'événement groupé avec l'auteur et les relays. Le 1 fait partie du séparateur Bech32, pas un numéro de version.

Où vivent les clés

Quand vous installez un client Nostr pour la première fois, il génère une paire de clés en demandant au système d'exploitation 32 octets aléatoires. C'est toute la cérémonie. Les clés sont vôtres dès que le générateur de nombres aléatoires termine.

Où le client les stocke dépend de l'application :

• Les applications mobiles natives stockent le nsec dans le trousseau du système d'exploitation (iOS Keychain, Android Keystore). Les deux sont chiffrés au repos avec le code d'accès ou la biométrie de l'appareil.
• Les clients basés sur navigateur vous demandent généralement d'installer une extension NIP-07 (nos2x, Alby, Flamingo) qui conserve le nsec dans le stockage sécurisé de l'extension. Le client ne voit jamais directement le nsec ; il demande à l'extension de signer les événements à la demande.
• Les clients qui sautent NIP-07 vous demanderont de coller le nsec dans le stockage local du navigateur, ce qui est moins sûr. C'est correct pour les comptes à faible enjeu et une mauvaise idée pour les comptes précieux.
• Les signataires Nostr de style portefeuille matériel (applications bunker, signataires distants) conservent le nsec sur un appareil séparé et signent à distance sur un canal chiffré. Le plus avancé, la surface d'attaque la plus faible.

Comment sauvegarder le nsec

La règle de sauvegarde la plus importante : le nsec doit exister dans au moins deux endroits, mais jamais dans un cloud que le fournisseur peut lire.

Bons endroits :

• 1Password, Bitwarden, KeePassXC, ou n'importe quel gestionnaire de mots de passe avec chiffrement de bout en bout
• iCloud Keychain (chiffré de bout en bout ; Apple ne peut pas le lire)
• Un morceau de papier imprimé dans un endroit physique sécurisé (un coffre-fort, un coffre de banque)
• Une plaque de sauvegarde en acier de style Bitcoin, si vous voulez une durabilité physique

Mauvais endroits :

• iCloud Notes, Google Keep, Evernote, OneNote (ceux-ci se synchronisent dans des formats que le fournisseur peut déchiffrer)
• Une capture d'écran dans votre rouleau caméra (automatiquement sauvegardée sur iCloud ou Google Photos en clair)
• Un email à vous-même
• Telegram « Messages enregistrés » ou toute autre application de chat auto-DM
• Un fichier en texte brut sur Dropbox, Google Drive, iCloud Drive

La distinction est : le fournisseur peut-il, s'il le voulait, lire le texte ? Si oui, l'endroit est dangereux. Si non (ou le fournisseur c'est vous avec une imprimante), l'endroit est sûr.

Pour les paranoïaques : le partage. Divisez le nsec en plusieurs morceaux à l'aide d'un schéma de seuil (Shamir's Secret Sharing) et stockez chaque morceau séparément. Deux morceaux sur trois reconstituent la clé. Excessif pour la plupart des utilisateurs, sensé pour les utilisateurs avec une identité de grande valeur.

Que se passe-t-il si vous perdez le nsec

Le compte est définitivement perdu. Il n'y a pas de flux de réinitialisation. Aucune entreprise n'en a de copie. Aucun tour cryptographique ne peut récupérer la clé à partir du seul npub.

La perte a trois conséquences pratiques :

• Vous ne pouvez plus publier à partir de cette identité.
• Vous ne pouvez plus recevoir de zaps à cette identité (l'adresse Lightning pointée dessus est toujours dans votre ancien événement de profil, mais comme vous ne pouvez pas mettre à jour votre profil, l'adresse peut devenir obsolète si le service sous-jacent change).
• Vous ne pouvez pas mettre à jour votre liste de suivi, votre profil ou répondre aux messages directs.

Vos messages restent sur les relays, lisibles par n'importe qui. Vos followers voient toujours les anciens messages dans leurs clients. Aucune nouvelle activité n'est possible.

La réponse pragmatique : générez une nouvelle paire de clés, publiez votre ancien npub avec une explication de « migration » pour quiconque regarde, et reconstruisez. Les gens qui veulent vous suivre à travers la rupture le feront ; vous en perdrez certains et en regagnerez d'autres. Il n'y a pas encore de moyen au niveau du protocole pour rendre cela sans friction.

Que se passe-t-il si quelqu'un obtient votre nsec

L'attaquant peut faire tout ce que vous pouviez faire :

• Publier sous votre identité (toujours)
• Lire vos messages directs déchiffrés
• Mettre à jour votre profil (y compris changer votre identifiant NIP-05)
• Envoyer des zaps en utilisant n'importe quel solde de portefeuille accessible à votre client
• Modifier votre liste de suivi

Ce qu'ils ne peuvent pas faire sans accès supplémentaire :

• Vider directement un portefeuille Lightning qui n'est pas jumelé avec le client
• Voler les zaps qui vous sont envoyés (ceux-ci vont à votre adresse Lightning configurée)
• Vous empêcher d'utiliser également la clé (vous l'avez toujours ; ce n'est pas un jeton d'authentification qui devient invalide)

La réponse immédiate à une compromission présumée de nsec est difficile. Contrairement à un mot de passe, les nsec nostr ne peuvent pas être révoqués. L'atténuation réaliste consiste à générer une nouvelle paire de clés, publier à partir de l'ancienne pour avertir tout le monde que vous faites pivoter, et basculer les identités. NIP-41 et des propositions similaires visent à rendre cela plus propre mais ne sont pas encore universellement supportées.

Identités multiples

De nombreux utilisateurs Nostr exécutent plus d'une identité. Un compte professionnel public, un compte personnel privé, un compte anonyme pour les communautés particulières. Chacun est une paire de clés séparée ; rien ne les lie cryptographiquement à moins que vous ne choisissiez de les lier en croisant les publications.

La plupart des clients supportent le basculement entre les identités à partir d'un menu. Les clés sont indépendantes ; le même client peut être connecté à tous et basculer avec un appui. C'est différent du multi-compte Twitter, où les identités sont des entrées dans la base de données de la plateforme ; sur Nostr, elles sont cryptographiquement sans rapport.

Un conseil pratique : étiquetez clairement les entrées du gestionnaire de mots de passe. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Les mélanger lors d'un copier-coller est un moyen de publier accidentellement à partir de la mauvaise identité.

Les clés sont le compte

Tout le reste sur Nostr (le nom lisible, la photo de profil, la biographie, les relays que vous utilisez, l'identifiant NIP-05) sont des métadonnées secondaires. Tout cela peut être remplacé ou déplacé. La paire de clés est la seule chose qui ne peut pas être remplacée sans recommencer.

Traitez le nsec en conséquence. Le sauvegarder prend deux minutes dès que vous le générez. Se rétablir d'un nsec perdu prend des semaines de reconstruction et ne fonctionne jamais tout à fait.

Une note sur la génération. La façon sûre d'obtenir une nouvelle paire de clés est de laisser un client la générer localement et de ne jamais transmettre la moitié privée sur le réseau. L'inscription de nostr.blog le fait côté client dans le navigateur ; le serveur ne voit jamais le nsec. Si un flux d'inscription envoie la clé privée à un serveur en premier, c'est un drapeau rouge. Partez et générez ailleurs.