Nostr keys explained: your digital identity in two strings

Your Nostr account is not a username-and-password combination. It is a pair of cryptographic keys, one public and one private, that you hold yourself. Every post you make is signed with the private key; every client that sees your post verifies the signature against your public key.

This is the single most important thing to understand about Nostr, because it shapes everything else. Your identity cannot be recovered if you lose it, because no company ever had a copy. Your account cannot be banned by a platform, because there is no platform database to remove it from. These are the same property viewed from different angles.

This guide explains what the keys are, what each one does, how they are encoded, and the specific mistakes that lose them.

TL;DR. Your npub1... is your public key. Safe to share anywhere. Your nsec1... is your private key. Keep it in a password manager or a printed piece of paper in a safe. Never paste it into a website form. Lose it and the identity is permanently gone.

When you're ready, grab your @nostr.blog address →

What a key pair actually is

A key pair is two numbers that are mathematically linked. The math is elliptic curve cryptography on a curve called secp256k1 (the same curve Bitcoin uses).

• The private key is a random 32-byte number. Any 256-bit random number works; nothing special about yours.
• The public key is derived from the private key by a specific calculation on the elliptic curve. Given the private key, computing the public key is fast. Given the public key, computing the private key back is believed to be practically impossible.

"Practically impossible" here means: no known algorithm can do it in a reasonable time on any computer that exists or that will plausibly exist. The security rests on this asymmetry. You publish the public key freely; you guard the private key absolutely.

What each key does

The public key is your identity. When someone follows you, they follow the public key. When someone mentions you, they tag the public key. When a relay stores your posts, it indexes them by public key. Every visible thing about you on the network is pegged to this one value.

The private key signs. Every event (post, reaction, follow list update, profile change) carries a Schnorr signature produced from the event's hash and the private key. Any client can run the reverse check: given the public key, the hash, and the signature, verify that only the holder of the matching private key could have produced that signature.

The result: relays and clients do not have to trust anyone. They verify signatures themselves. A forged post with an invalid signature gets dropped silently. A real post signed by the right key is accepted no matter which relay served it.

How the keys are encoded

A raw 32-byte number is inconvenient to look at or type. Nostr uses two encoding conventions.

Hex. The raw bytes written as lowercase hexadecimal: 64 characters, a-f and 0-9. This is the canonical form that appears inside NIP-05 JSON files and most protocol internals.

Example public key in hex: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. The same bytes wrapped in a human-oriented format with a prefix and a checksum. The prefix tells humans (and software) what kind of thing they are looking at. npub1 means "this is a Nostr public key." nsec1 means "this is a Nostr private key."

Example public key in Bech32: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

The checksum in Bech32 is important. If you accidentally change one character, the checksum fails and any tool rejects the key as invalid. This prevents silent corruption during copy-paste. Hex has no such safety; a single wrong character in a hex key will produce a different (but valid-looking) identity.

Prefixes exist for other kinds of Nostr data too. note1 is an event ID. nprofile1 is a public key bundled with recommended relays. nevent1 is an event ID bundled with author and relays. The 1 is part of the Bech32 separator, not a version number.

Where the keys live

When you install any Nostr client for the first time, it generates a key pair by asking the operating system for 32 random bytes. That is the whole ceremony. The keys are yours the moment the random number generator finishes.

Where the client stores them depends on the app:

• Native mobile apps store the nsec in the OS keychain (iOS Keychain, Android Keystore). Both are encrypted at rest with the device's passcode or biometric.
• Browser-based clients usually ask you to install a NIP-07 extension (nos2x, Alby, Flamingo) which holds the nsec in the extension's secure storage. The client never sees the nsec directly; it asks the extension to sign events on demand.
• Clients that skip NIP-07 will ask you to paste the nsec into local browser storage, which is less secure. This is fine for low-stakes accounts and a bad idea for valuable ones.
• Hardware-wallet-style Nostr signers (bunker apps, remote signers) hold the nsec on a separate device and sign remotely over an encrypted channel. Most advanced, lowest attack surface.

How to back up the nsec

The single most important backup rule: the nsec must exist in at least two places, but never in a cloud that the provider can read.

Good places:

• 1Password, Bitwarden, KeePassXC, or any password manager with end-to-end encryption
• iCloud Keychain (end-to-end encrypted; Apple cannot read it)
• A printed piece of paper in a secure physical location (a safe, a safety deposit box)
• A Bitcoin-style steel backup plate, if you want physical durability

Bad places:

• iCloud Notes, Google Keep, Evernote, OneNote (these sync in formats the provider can decrypt)
• A screenshot in your camera roll (auto-backed-up to iCloud or Google Photos in plaintext)
• Email to yourself
• Telegram "Saved Messages" or any other chat app self-DM
• A plaintext file on Dropbox, Google Drive, iCloud Drive

The distinction is: can the provider, if they wanted to, read the text? If yes, the location is unsafe. If no (or the provider is you with a printer), the location is safe.

For the paranoid: sharding. Split the nsec into multiple pieces using a threshold scheme (Shamir's Secret Sharing) and store each piece separately. Two out of three pieces reconstruct the key. Overkill for most users, sensible for users with a high-value identity.

What happens if you lose the nsec

The account is permanently gone. There is no reset flow. No company has a copy. No cryptographic trick can recover the key from the npub alone.

The loss has three practical consequences:

• You can no longer post from that identity.
• You can no longer receive zaps to that identity (the Lightning address pointed at it is still in your old profile event, but since you cannot update your profile, the address may become stale if the underlying service changes).
• You cannot update your follow list, your profile, or respond to direct messages.

Your posts remain on relays, readable by anyone. Your followers still see the old posts in their clients. New activity is impossible.

The pragmatic response: generate a fresh key pair, post your old npub with a "migration" explanation for anyone watching, and rebuild. People who want to follow you across the break will do so; you will lose some and regain others. There is no protocol-level way to make this frictionless yet.

What happens if someone gets your nsec

The attacker can do everything you could do:

• Post under your identity (forever)
• Read your decrypted direct messages
• Update your profile (including changing your NIP-05 identifier)
• Send zaps using any wallet balance accessible to your client
• Change your follow list

What they cannot do without additional access:

• Directly drain a Lightning wallet that is not paired with the client
• Steal zaps sent to you (those go to your configured Lightning address)
• Prevent you from also using the key (you still have it; this is not an authentication token that gets invalidated)

The immediate response to suspected nsec compromise is hard. Unlike a password, nostr nsecs cannot be revoked. The realistic mitigation is to generate a new key pair, post from the old one to warn everyone you are rotating, and switch identities. NIP-41 and similar proposals aim to make this cleaner but are not yet universally supported.

Multiple identities

Many Nostr users run more than one identity. A public-facing professional account, a private personal account, an anonymous account for particular communities. Each is a separate key pair; nothing ties them cryptographically unless you choose to link them by cross-posting.

Most clients support switching between identities from a menu. The keys are independent; the same client can be logged into all of them and switch with a tap. This is different from Twitter multi-account, where the identities are entries in the same platform's database; on Nostr they are cryptographically unrelated.

One practical tip: label the password manager entries clearly. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Mixing them up during a copy-paste is a way to accidentally post from the wrong identity.

The keys are the account

Everything else in Nostr (the readable name, the profile picture, the bio, the relays you use, the NIP-05 identifier) is secondary metadata. All of it can be replaced or moved. The key pair is the one thing that cannot be replaced without starting over.

Treat the nsec accordingly. Backing it up takes two minutes the moment you generate it. Recovering from a lost nsec takes weeks of rebuilding and never quite works.

A note on generation. The safe way to get a new key pair is to let a client generate it locally and never transmit the private half over the network. nostr.blog's signup does this client-side in the browser; the server never sees the nsec. If any signup flow sends the private key to a server first, that is a red flag. Walk away and generate elsewhere.