nsec vs npub: wat elk is, en hoe ze niet door elkaar te halen

Elke Nostr-gebruiker ziet binnen een minuut na het aanmaken van een account twee tekenreeksen die beginnen met npub1 en nsec1. Ze zien er bijna identiek uit, ze hebben dezelfde lengte, en ze zien er beide uit als willekeurige karakters. Ze door elkaar halen is een van de meest voorkomende en meest ernstige fouten op het netwerk.

Deze handleiding maakt het verschil duidelijk, visueel en conceptueel, zodat je ze nooit meer verwarrt.

TL;DR. npub1... is je publieke sleutel: veilig om te delen, dit is wat je uitdeelt. nsec1... is je privésleutel: nooit delen, nooit in een website plakken, nooit opslaan in cloud-aantekeningen. Beide zijn 63 karakters lang. De eerste drie letters zijn het enige wat ertoe doet.

Als je er klaar voor bent, claim je @nostr.blog-adres →

Het onderscheid in één regel

Je sleutelpaar heeft twee helften.

• npub = nostr publiek. De identificator die je plaatst, deelt en gebruikt als je "accountnaam."
• nsec = nostr secret. Het cryptografische geheim dat bewijst dat je de account bezit.

"npub" bevat het woord "pub" voor publiek. "nsec" bevat "sec" voor secret. Deze geheugensteun is niet toevallig; de ontwerpers hebben prefixen gekozen die zelfverklarend zijn.

Wat je eigenlijk ziet

Beide tekenreeksen zijn 63 karakters lang. Beide beginnen met n en daarna een drielettergig voorvoegsel. Beide gebruiken kleine letters a-z en cijfers 0-9 uit een beperkt Bech32-alfabet.

npub-voorbeeld:

npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

nsec-voorbeeld (dit is verzonnen; deel nooit een echte nsec):

nsec1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

Ze verschillen alleen in het voorvoegsel na de n. pub vs sec. Elk ander karakter kan van alles zijn; dat voorvoegsel is de enige plaats waar je ze uit elkaar kunt houden.

Waar elk afkomstig is

Wanneer je een Nostr-client voor het eerst opent, genereert het 32 willekeurige bytes en noemt dat je privésleutel. Dit wordt je nsec na Bech32-codering. Vervolgens voert de client één wiskundige bewerking uit (elliptische-curve-vermenigvuldiging op secp256k1) om een bijbehorende publieke sleutel af te leiden, en codeert die als Bech32 in je npub.

De relatie is eenrichtingsverkeer. Met de nsec is het afleiden van de npub snel. Met de npub terugkeren naar de nsec is naar verluidt onmogelijk met elke computer die bestaat of waarschijnlijk zal bestaan.

Dit is waarom je je npub op je website, op Twitter, op visitekaartjes en in je e-mailhandtekening kunt publiceren zonder enig veiligheidsrisico. Het is ook waarom het verliezen van je nsec een onherstelbare ramp is: niemand, niet eens jij, kan het reconstrueren vanuit de npub.

Waarvoor elke sleutel wordt gebruikt

De nsec heeft precies één taak: berichten ondertekenen. Elke keer dat je iets plaatst, reageert, iemand volgt, je profiel bijwerkt of een directe bericht verzendt, maakt je client een bericht aan en ondertekent het met de nsec. De handtekening gaat in het bericht voordat het naar relays wordt gepubliceerd.

De npub heeft verschillende taken:

• Identiteit. Wanneer iemand je volgt, verwijzen ze naar je npub.
• Verificatie. Elke client die een bericht ontvangt, controleert de handtekening tegen de npub die aan het bericht is gekoppeld. Een geldige handtekening betekent dat het bericht afkomstig is van degene die de bijbehorende nsec bezit.
• Routering. Relays gebruiken de npub in filters. Abonneren op "berichten van npub X" is hoe je volgers je berichten krijgen.
• Vermeldingen. Wanneer iemand je in een bericht tagt, voegen ze je npub in de berichtmarkeringen in.

De nsec verschijnt nooit op het netwerk. Het blijft op je apparaat (of een vertrouwde ondertekenaar zoals een NIP-07-extensie of een externe ondertekenaar-app). De npub is voortdurend op het netwerk, gekoppeld aan elk bericht dat je ondertekent.

Veelgemaakte verwisselingen en hun gevolgen

Verwisseling 1: Je nsec plakken waar een npub wordt gevraagd.

Scenario: een profielbewerking zegt "je publieke sleutel" en je plakt per ongeluk de nsec in. Gevolg: afhankelijk van de client, kan het formulier je waarschuwen (goede clients controleren het voorvoegsel en weigeren nsec in publieke velden). Slechte clients kunnen de nsec ergens publiceren waar het niet thuishoort. Controleer altijd het drielettergig voorvoegsel voordat je plakt.

Verwisseling 2: Je nsec op sociale media plaatsen als demo.

Elk jaar plaatst een nieuwe gebruiker een schermafbeelding van hun "Nostr-accountdetails" die beide tekenreeksen bevat. Gevolg: iedereen die de schermafbeelding ziet kan nu berichten als die gebruiker ondertekenen tot ze beseffen wat er is gebeurd en roteren. De oplossing is alleen de npub-helft te delen.

Verwisseling 3: De nsec "tijdelijk" in cloud-aantekeningen opslaan.

Scenario: je genereert een sleutelpaar, wilt het naar een tweede apparaat kopiëren en plakt de nsec in iCloud Notes of een Gmail-concept om het over te dragen. Gevolg: die provider bezit nu je nsec in een vorm die ze kunnen lezen. Een inbreuk bij die provider is een inbreuk op je Nostr-identiteit. Gebruik een wachtwoordmanager met end-to-end-versleuteling, of (voor eenmalige overdracht) een QR-code die je tussen apparaten scant zonder op te slaan op een cloud-gesynchroniseerde locatie.

Verwisseling 4: De nsec in een websiteloginformulier plakken.

Scenario: een nieuwe Nostr-web-app vraagt je nsec om je "in te loggen." Gevolg: die website heeft nu je nsec permanent, zelfs nadat je het tabblad sluit. Doe dit nooit. Reputabele web-clients gebruiken in plaats daarvan een NIP-07-browserextensie; de extensie bevat de nsec en ondertekent alleen op verzoek, zonder het onbewerkte geheim aan de webpagina bloot te stellen.

De Bech32-checksumtrick

Zowel npub als nsec gebruiken Bech32-codering, die een ingebouwde foutdetectie-checksum bevat. Als je één karakter van een npub of nsec wijzigt, mislukt de checksum en weigert elk compatibel hulpprogramma de tekenreeks als ongeldig.

Dit is praktisch nuttig: als je een sleutel kopieert en plakt en een karakter wordt verwijderd of vervangen, zal het ontvangende hulpprogramma je dit onmiddellijk zeggen, in plaats van stilzwijgend een ander (geldig uitziend) identiteit te accepteren.

Hex-gecodeerde sleutels hebben deze eigenschap niet. Een enkel verkeerd karakter in een hex-sleutel produceert een ander maar "geldig" sleutel dat naar een volledig ander identiteit wijst. Gebruik altijd de Bech32-vorm (npub/nsec) bij het plakken van sleutels tussen systemen.

Hoe je kunt controleren welke je bekijkt

De eerste vier karakters. Dat is de hele controle.

• Begint met npub1: veilig om te delen, het is de publieke helft.
• Begint met nsec1: deel onder geen enkel omstandigheid, het is de geheime helft.
• Begint met note1: dit is een bericht-ID (voor een specifieke post), niet een sleutel.
• Begint met nprofile1: dit is een publieke sleutel gebundeld met aanbevolen relays.
• Begint met nevent1: dit is een bericht-ID gebundeld met auteur en relays.
• Begint met naddr1: dit is een adres voor een lang artikel.

Een nuttige mentaleregel: elke Bech32-tekenreeks die begint met nsec blijft op je apparaat. Alles anders (npub, note, nprofile, nevent, naddr) is bedoeld om te worden gedeeld.

Een concreet veiligheidsritueel

Op het moment dat je een nieuwe Nostr-identiteit genereert, doe je dit:

1. Open je wachtwoordmanager.
2. Maak een nieuw item aan met het label "Nostr nsec [accountnaam]."
3. Plak de nsec in het wachtwoordveld.
4. Opslaan.
5. Sluit de app.

Totale tijd: 30 seconden. Alternatief: druk de nsec af op een stuk papier met een betrouwbare printer en berg het papier ergens op waar je het niet kwijtraakt. Vijf minuten.

Nu heb je een hersteelpad. De nsec bevindt zich op een plaats die is versleuteld met je masterwachtwoord of volledig offline. Als je je telefoon kwijtraakt, kun je je aanmelden op de nieuwe door de nsec terug in te plakken. Als je je laptop kwijtraakt, hetzelfde.

De ene plaats waar mensen zich tegen verzetten: ze genereren sleutels op hun telefoon, de nsec zit in de sleutelhanger, "ik back het later wel up." Later komt nooit. Dan wissen ze de telefoon, of upgraden, of verliezen deze, en de identiteit is weg. De back-up is de enige stap die dit voorkomt en het kost minder tijd dan het lezen van deze paragraaf.