• The pitch sounds great
• Lose it or have it stolen: pick your disaster
• The nsec-pasting era
• NIP-49: the first real fix
• Remote signing: the key that stays home
• Multi-sig: the idea that isn’t ready yet
• A practical key management checklist
• The gap is real

§The pitch sounds great

If you’ve spent any time around #nostr, you’ve heard the pitch. Your keypair is your identity. No company controls it. No platform can ban it. You generate a key, and that key is you. Forever.

All of that is true. What nobody mentions at the meetup is what “forever” actually means when things go wrong.

A password protects your access to an account that someone else owns. If you forget it, you reset it. If it gets stolen, you change it. The account itself is a separate thing, managed by a company with recovery flows and support tickets and “click here to verify your identity.”

Your #nostr nsec is not a password. It is the account. There is no separation between the credential and the identity. Lose the key, lose the identity. Leak the key, and whoever has it becomes you. No reset. No recovery. No support ticket.

Most Nostr users figure this out the hard way. Their first interaction with their nsec is copying it from one app and pasting it into another. Maybe they screenshot it. Maybe it ends up in a notes app that syncs to iCloud. The onboarding pitch was about sovereignty. The actual onboarding experience is a clipboard copy with your entire digital identity in it.

I’ve had this conversation enough times to notice the gap between how we talk about Nostr keys and how people actually handle them. That gap is the subject of this article.

§Lose it or have it stolen: pick your disaster

There are two ways your key management can fail, and they are not equivalent.

If you lose your nsec, your identity is gone. Your followers, your contact list, your DM history, your NIP-05 verification, your web-of-trust position, any Lightning address linked to your profile. All of it. There is no seed phrase (unless a specific client implemented one). There is no social recovery mechanism in the protocol. You generate a new keypair and start from zero, hoping people figure out you’re the same person.

If someone steals your nsec, it’s worse. The attacker does not just gain access to your account. They become your account. They can sign events as you. They can read your encrypted DMs. And there is no revocation. The Nostr protocol has no concept of invalidating a compromised key.

You could publish a note saying “my key was compromised, this identity is burned.” The attacker could publish one saying “ignore that message, I’m fine.” The protocol cannot distinguish between these two events. Both are validly signed by the same key.

Compare this to a password breach on a normal platform. Someone gets your Gmail password: you reset it, enable 2FA, review login history, done. The damage is bounded and reversible. Someone gets your nsec: there is no equivalent action.

A 2025 academic paper titled “Not in The Prophecies: Practical Attacks on Nostr” identified structural problems in the protocol, including a lack of authenticity guarantees for public keys and gaps in signature verification. These are not UX complaints. They are protocol-level findings. The researchers found that the cryptographic identity model that makes Nostr compelling is also what makes key compromise permanent.

§The nsec-pasting era

Here is how onboarding works in most Nostr clients. You open the app. It generates a keypair. It shows you an nsec string and tells you to save it somewhere safe. You copy it. You paste it into your password manager, or your notes app, or a text file on your desktop. Then when you want to use a second client, you paste the nsec there too.

That copy-paste moment is where the threat model breaks.

The clipboard is a shared system resource. On Windows, clipboard history stores the last 25 items by default, and you can access anything you copied recently by pressing Win+V. On macOS, the universal clipboard syncs across devices via iCloud, which means your nsec might exist on your iPhone, your iPad, and your MacBook simultaneously. On Android, many keyboard apps log clipboard contents for autocomplete purposes. Cloud clipboard sync means your nsec may end up on servers you have no control over.

Some clients have started fighting back. Damus detects when a user tries to paste an nsec into a post and automatically substitutes their npub instead. The developer of Coracle committed to removing nsec login entirely, writing that the era of nsec-pasting is over. He’s right, but the ecosystem hasn’t caught up yet. Most clients still accept raw nsec input.

Real users have posted on Nostr about pasting their nsec into the wrong field and considering their identity compromised. This is not a theoretical risk. It happens, and when it does, there is no undo.

The attack surface also overlaps with existing threats. Clipboard hijacking malware that targets cryptocurrency addresses already exists in the wild. Nostr nsec keys use the same bech32 encoding. If a piece of malware is scanning your clipboard for strings that start with bc1 or lnbc, adding nsec1 to the pattern list is trivial.

§NIP-49: the first real fix

NIP-49 defines ncryptsec, a format for encrypting your private key with a password. Instead of storing a raw nsec, you encrypt it once and store the result. The raw key never needs to exist on disk.

The encryption uses scrypt for key derivation. A parameter called log_n controls how expensive decryption is. At log_n=16, decryption requires roughly 64 MiB of memory and takes about 100 milliseconds on a fast machine. At log_n=20, it requires about 1 GiB and takes around 2 seconds. Each step up doubles the cost. This matters because it determines how much an attacker pays per brute-force guess against your password.

The encryption is non-deterministic. A random nonce means that encrypting the same key with the same password produces a different ncryptsec each time. This prevents comparison attacks where someone could tell whether two encrypted strings protect the same key.

NIP-49 also includes a key #security flag. A value of 0x00 means the key has been handled insecurely at some point during its lifetime, such as appearing in a clipboard or being displayed on screen. A value of 0x01 means the key was generated and encrypted in one step without exposure. Clients are supposed to set this flag honestly. It gives downstream tools a signal about how much to trust the encryption.

In practice, using ncryptsec looks like this:

from nostr_sdk import EncryptedSecretKey, Keys, NostrSigner
from pathlib import Path

ncryptsec = Path("keys/identity.ncryptsec").read_text().strip()
encrypted = EncryptedSecretKey.from_bech32(ncryptsec)
secret_key = encrypted.decrypt(passphrase)
keys = Keys(secret_key)
signer = NostrSigner.keys(keys)

The passphrase lives in a .env file that is gitignored. The ncryptsec file is safe to commit to version control because it requires the passphrase to decrypt. The plaintext nsec exists only in memory, briefly, and is discarded after signing.

One thing to watch out for: ncryptsec should not be published to Nostr relays. If someone posts their ncryptsec to a relay, anyone can download it and run an offline brute-force attack against the password. The scrypt parameters make this expensive, but “expensive” is relative to the password strength. A weak password with a strong KDF is still a weak password. NIP-49 is protection at rest, not protection from distribution.

§Remote signing: the key that stays home

NIP-46, also called Nostr Connect, takes a different approach. Instead of encrypting the key and storing it on the same machine that uses it, the key lives somewhere else entirely. A separate device or server, called a “signer” or “bunker,” holds the private key. The client you use day-to-day never sees the raw nsec.

The flow works like this. The client generates ephemeral app keys and connects to the remote signer through Nostr relays. When the client needs to sign an event, it sends a request over NIP-44 encrypted messages. The signer approves the request and returns the signed event. The private key never leaves the signer’s device.

Several implementations exist and are actively maintained. nsecBunker runs as a server. Amber is an Android app that acts as a local signer. nsec.app runs in a browser service worker. Noauth provides a web-based key manager.

The tradeoff is availability. The signer must be online when you want to sign. For interactive use, where you’re browsing Nostr and posting manually, this works well. For automation, like a scheduled post system or a feed monitor that runs 24/7, the signer needs to be always-on. That adds a dependency.

I evaluated NIP-46 for my own setup and concluded: don’t implement now, but prepare for it. The current approach of NIP-49 encrypted keys with in-process nostr-sdk signing is already solid. The plaintext nsec exists only in memory, never in process arguments, and the .env plus ncryptsec combination provides at-rest encryption. NIP-46 becomes worth the complexity when the identity is high-value enough to justify the operational overhead, or when the machine running the automation cannot be fully trusted.

The nostr-sdk #python library already includes a NostrConnect client that implements the same signer interface as Keys. The switch could be transparent to every script in the system if the architecture is right.

§Multi-sig: the idea that isn’t ready yet

Frostr implements threshold signing for Nostr. Instead of one key that can sign events, you split the signing capability across multiple keys. A 2-of-3 setup means any two of three key holders must cooperate to produce a valid signature. No single key can sign alone.

This is the strongest theoretical answer to key management. If one device is compromised, the attacker cannot sign. If one device is lost, you can still sign with the others. The single point of failure that makes Nostr key management scary goes away.

But Frostr is early. Client support is minimal. The coordination protocol between signers adds complexity that most users cannot manage today. This is something to watch, not something to set up this weekend.

§A practical key management checklist

Here is what I’d tell someone setting up a #nostr identity today, in order of increasing #security.

The minimum you should do:

Generate your key in a client that supports NIP-49, or encrypt it immediately using a tool like nak. Store the ncryptsec file with a strong passphrase. Delete any plaintext nsec from your clipboard, your notes app, your password manager’s “notes” field, and anywhere else you stashed it during onboarding. If you ever pasted your nsec into an app, accept that it touched the clipboard and may have been logged. Stop pasting nsec into clients. If a client requires raw nsec input and has no alternative, find a different client.

Better:

Use a browser extension signer like nos2x or Alby. Your nsec lives in one place, inside the extension, and web clients request signatures without ever seeing the raw key. Keep the ncryptsec passphrase in a proper password manager, stored separately from the ncryptsec file itself. This gives you two-location security: the encrypted key in one place, the password to decrypt it in another.

Best, for identities worth protecting:

Use a remote signer. Amber on Android or nsecBunker on a server. The machine you use to post never holds the key. Watch Frostr development. When threshold signing gets client support, a 2-of-3 setup will be the strongest available option.

And know what you cannot do. There is no protocol-level account recovery. No seed phrase unless a specific client added one. No social recovery NIP has been adopted. If your key management fails, the protocol will not save you. Understanding that gap is itself a form of security, because it changes how carefully you treat the key.

§The gap is real

“Your keypair is your identity” is a true statement and an incomplete one. Generating the key takes seconds. Protecting it is an ongoing problem that the protocol does not solve for you.

The tooling is getting better. NIP-49 gives you encrypted storage. NIP-46 gives you remote signing. Extension signers give you a safer login flow. Frostr may eventually give you fault tolerance. But right now, in 2026, most Nostr users are carrying their identity in a way that would make any #privacy-conscious engineer wince.

A protocol built on the premise that you own your identity gives you remarkably few tools to protect it. That’s the gap. It’s worth knowing about before your clipboard decides to close it for you.

#nostr #security #privacy #cryptography