Nostr sleutels uitgelegd: uw digitale identiteit in twee strings

Uw Nostr-account is geen combinatie van gebruikersnaam en wachtwoord. Het is een paar cryptografische sleutels, één openbaar en één privé, die u zelf in handen houdt. Elk bericht dat u plaatst, wordt ondertekend met de privésleutel; elke client die uw bericht ziet, controleert de handtekening tegen uw openbare sleutel.

Dit is het allerbelangrijkste wat u over Nostr moet begrijpen, omdat het alles wat volgt bepaalt. Uw identiteit kan niet worden hersteld als u deze verliest, omdat geen bedrijf ooit een kopie had. Uw account kan niet door een platform worden verbannen, omdat er geen platformdatabase is waaruit het kan worden verwijderd. Dit zijn dezelfde eigenschap vanuit verschillende invalshoeken bekeken.

Deze gids legt uit wat de sleutels zijn, wat elk ervan doet, hoe ze worden gecodeerd, en de specifieke fouten die ze verliezen.

TL;DR. Uw npub1... is uw openbare sleutel. Veilig om overal te delen. Uw nsec1... is uw privésleutel. Bewaar deze in een wachtwoordmanager of een gedrukt stuk papier in een kluis. Plak het nooit in een websiteformulier. Verlies het en de identiteit is permanent weg.

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

Wat een sleutelpaar eigenlijk is

Een sleutelpaar bestaat uit twee getallen die wiskundig aan elkaar zijn gekoppeld. De wiskunde is elliptische-curvecryptografie op een curve genaamd secp256k1 (dezelfde curve die Bitcoin gebruikt).

• De privésleutel is een willekeurig 32-byte getal. Elk 256-bits willekeurig getal werkt; er is niets bijzonders aan de jouwe.
• De openbare sleutel wordt afgeleid van de privésleutel door een specifieke berekening op de elliptische curve. Gegeven de privésleutel is het berekenen van de openbare sleutel snel. Gegeven de openbare sleutel is het terug berekenen van de privésleutel waarschijnlijk praktisch onmogelijk.

"Praktisch onmogelijk" betekent hier: er is geen bekend algoritme dat dit in een redelijke tijd kan doen op een computer die bestaat of waarschijnlijk zal bestaan. De veiligheid berust op deze asymmetrie. U publiceert de openbare sleutel vrij; u bewaart de privésleutel absoluut.

Wat elke sleutel doet

De openbare sleutel is uw identiteit. Wanneer iemand u volgt, volgen zij de openbare sleutel. Wanneer iemand u noemt, taggen zij de openbare sleutel. Wanneer een relay uw berichten opslaat, indexeert het deze op openbare sleutel. Alles wat zichtbaar is over u op het netwerk is gekoppeld aan deze ene waarde.

De privésleutel ondertekent. Elk event (bericht, reactie, volgende-lijstupdate, profielwijziging) draagt een Schnorr-handtekening voort die wordt geproduceerd uit de hash van het event en de privésleutel. Elke client kan de reverse check uitvoeren: gegeven de openbare sleutel, de hash en de handtekening, verifiëren dat alleen de houder van de overeenkomstige privésleutel die handtekening kon hebben geproduceerd.

Het resultaat: relays en clients hoeven niemand te vertrouwen. Ze verifiëren handtekeningen zelf. Een vervalst bericht met een ongeldige handtekening wordt stil verworpen. Een echt bericht ondertekend door de juiste sleutel wordt zonder voorbehoud geaccepteerd, ongeacht welke relay het serveerde.

Hoe de sleutels worden gecodeerd

Een raw 32-byte getal is onpraktisch om naar te kijken of in te typen. Nostr gebruikt twee codeingsconventies.

Hex. De raw bytes geschreven als kleine letters hexadecimaal: 64 tekens, a-f en 0-9. Dit is de canonieke vorm die in NIP-05 JSON-bestanden en de meeste protocolinternals verschijnt.

Voorbeeld openbare sleutel in hex: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Dezelfde bytes ingepakt in een mensgerichte indeling met een voorvoegsel en een controlesom. Het voorvoegsel vertelt mensen (en software) wat voor soort ding ze bekijken. npub1 betekent "dit is een Nostr openbare sleutel." nsec1 betekent "dit is een Nostr privésleutel."

Voorbeeld openbare sleutel in Bech32: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

De controlesom in Bech32 is belangrijk. Als u per ongeluk één teken wijzigt, mislukt de controlesom en weigert elk hulpmiddel de sleutel als ongeldig. Dit voorkomt stille corruptie tijdens kopiëren en plakken. Hex heeft geen dergelijke veiligheid; een enkel onjuist teken in een hex-sleutel zal een ander (maar geldig uitziend) identiteit produceren.

Voorvoegsels bestaan ook voor andere soorten Nostr-gegevens. note1 is een event-ID. nprofile1 is een openbare sleutel gebundeld met aanbevolen relays. nevent1 is een event-ID gebundeld met auteur en relays. De 1 is onderdeel van het Bech32-scheidingsteken, geen versienummer.

Waar de sleutels wonen

Wanneer u voor het eerst een Nostr-client installeert, genereert deze een sleutelpaar door het besturingssysteem om 32 willekeurige bytes te vragen. Dat is de hele ceremonie. De sleutels zijn van u zodra de toevalsgenerator klaar is.

Waar de client ze opslaat, hangt af van de app:

• Native mobiele apps slaan de nsec in de OS-sleutelhanger op (iOS Keychain, Android Keystore). Beide zijn versleuteld in rust met de wachtwoordcode of biometrie van het apparaat.
• Browsers-gebaseerde clients vragen u meestal een NIP-07-extensie te installeren (nos2x, Alby, Flamingo), die de nsec in beveiligde opslag houdt. De client ziet de nsec nooit rechtstreeks; het vraagt de extensie op aanvraag om events te ondertekenen.
• Clients die NIP-07 overslaan, zullen u vragen de nsec in lokale browseropslag te plakken, wat minder veilig is. Dit is goed voor accounts met lage inzetten en een slecht idee voor waardevolle.
• Hardware-wallet-stijl Nostr-ondertekenaar (bunker-apps, externe ondertekenaar) houdt de nsec op een afzonderlijk apparaat en ondertekent extern via een versleuteld kanaal. Meest geavanceerd, laagste aanvalsoppervlak.

Hoe u de nsec kunt backuppen

De enige meest belangrijke backupregel: de nsec moet op minstens twee plaatsen bestaan, maar nooit in een cloud die de provider kan lezen.

Goede plaatsen:

• 1Password, Bitwarden, KeePassXC, of elke wachtwoordmanager met end-to-end-versleuteling
• iCloud Keychain (end-to-end versleuteld; Apple kan het niet lezen)
• Een gedrukt stuk papier op een veilige fysieke locatie (een kluis, een veiligheidsloket)
• Een Bitcoin-stijl stalen backupplaat, als u fysieke duurzaamheid wilt

Slechte plaatsen:

• iCloud Notes, Google Keep, Evernote, OneNote (deze synchroniseren in formaten die de provider kan ontsleutelen)
• Een schermafbeelding in uw fotorol (automatisch back-upd naar iCloud of Google Photos in leesbare tekst)
• E-mail naar jezelf
• Telegram "Opgeslagen berichten" of elke andere chat-app zelf-DM
• Een leesbaar tekstbestand op Dropbox, Google Drive, iCloud Drive

Het onderscheid is: kan de provider, als zij willen, de tekst lezen? Zo ja, de locatie is onveilig. Zo nee (of de provider bent u met een printer), de locatie is veilig.

Voor de paranoïde: sharding. Splits de nsec in meerdere stukken met behulp van een drempelschema (Shamir's Secret Sharing) en sla elk stuk apart op. Twee van drie stukken stellen de sleutel opnieuw samen. Overkill voor de meeste gebruikers, verstandig voor gebruikers met een waardevol identiteit.

Wat gebeurt er als u de nsec verliest

Het account is permanent weg. Er is geen resetprocedure. Geen bedrijf heeft een kopie. Geen cryptografische truc kan de sleutel uit de npub alleen herstellen.

Het verlies heeft drie praktische gevolgen:

• U kunt niet meer vanuit die identiteit plaatsen.
• U kunt geen zaps meer ontvangen naar die identiteit (het Lightning-adres waarnaar wordt verwezen, blijft in uw oude profielevent, maar aangezien u uw profiel niet kunt bijwerken, kan het adres achterhaald raken als de onderliggende service verandert).
• U kunt uw volgende lijst, uw profiel of antwoord geven op directe berichten niet bijwerken.

Uw berichten blijven op relays, leesbaar door iedereen. Uw volgers zien de oude berichten nog steeds in hun clients. Nieuwe activiteit is onmogelijk.

Het pragmatische antwoord: genereer een nieuw sleutelpaar, plaats uw oude npub met een "migratie" uitleg voor iedereen die kijkt, en herbouw. Mensen die u over de breuk willen volgen, zullen dat doen; u zult sommigen verliezen en anderen teruggain. Er is nog geen protocolmanier om dit wrijvingsloos te maken.

Wat gebeurt er als iemand uw nsec krijgt

De aanvaller kan alles doen wat u kon doen:

• Post onder uw identiteit (voor altijd)
• Lees uw ontsleutelde directe berichten
• Werk uw profiel bij (inclusief het wijzigen van uw NIP-05-identifier)
• Stuur zaps met behulp van enig walletbestand dat toegankelijk is voor uw client
• Wijzig uw volgende lijst

Wat ze zonder extra toegang niet kunnen doen:

• Direct een Lightning-portemonnee leegmaken die niet aan de client is gekoppeld
• Zaps stelen die naar u zijn verzonden (die gaan naar uw geconfigureerde Lightning-adres)
• U voorkomen de sleutel ook te gebruiken (u hebt deze nog steeds; dit is geen verificatietoken dat ongeldig wordt gemaakt)

Het onmiddellijke antwoord op vermoede nsec-inbreuk is moeilijk. In tegenstelling tot een wachtwoord kunnen nostr nsecs niet worden ingetrokken. De realistische beperking is een nieuw sleutelpaar genereren, uit de oude account posten om iedereen te waarschuwen dat u roteert, en van identiteit wisselen. NIP-41 en soortgelijke voorstellen zijn erop gericht dit schoner te maken, maar worden nog niet universeel ondersteund.

Meervoudige identiteiten

Veel Nostr-gebruikers voeren meer dan één identiteit uit. Een publiekelijk gericht professioneel account, een privé persoonlijk account, een anoniem account voor bepaalde gemeenschappen. Elk is een afzonderlijk sleutelpaar; niets bindt ze cryptografisch tenzij u ervoor kiest ze te koppelen door te kruisposten.

De meeste clients ondersteunen het wisselen tussen identiteiten vanuit een menu. De sleutels zijn onafhankelijk; dezelfde client kan in al deze instellingen zijn aangemeld en met een tik wisselen. Dit verschilt van Twitter multi-account, waar de identiteiten vermeldingen in dezelfde platformdatabase zijn; op Nostr zijn ze cryptografisch niet gerelateerd.

Een praktische tip: label de items in de wachtwoordmanager duidelijk. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Ze verwisselen tijdens kopiëren en plakken is een manier om per ongeluk vanuit de verkeerde identiteit te posten.

De sleutels zijn het account

Al het andere in Nostr (de leesbare naam, de profielfoto, de bio, de relays die u gebruikt, de NIP-05-identifier) is secundaire metagegevens. Al dit kan worden vervangen of verplaatst. Het sleutelpaar is het enige wat niet kan worden vervangen zonder opnieuw te beginnen.

Behandel de nsec dienovereenkomstig. Back-ups maken duurt twee minuten op het moment dat u deze genereert. Herstellen van een verloren nsec duurt weken herstellen en werkt nooit helemaal.

Een opmerking over generatie. De veilige manier om een nieuw sleutelpaar te krijgen is om een client lokaal te genereren en de privéhelft nooit via het netwerk over te dragen. nostr.blog's aanmelding doet dit client-zijdig in de browser; de server ziet de nsec nooit. Als enige aanmeldingsstroom de privésleutel eerst naar een server stuurt, is dat een waarschuwing. Loop weg en genereer ergens anders.