KeytrPasskey Login for Nostr Keys

What Is an nsec Key and Why Does It Matter?

On Nostr, every identity is built from a pair of keys. The public key, usually shown as an npub, is shared openly so others can find and follow you. The private key, called the nsec, proves that you control the identity. Anyone who holds the nsec can sign posts and messages as that person.

This is what makes the nsec so sensitive. Unlike a typical website account, there is usually no central support desk that can reset it for you. If the key is exposed, the identity is exposed too. Many people copy their nsec into notes, password managers or clipboard history, and every extra copy adds another place where it can leak.

Keytr starts from a simple idea: the raw key should not sit in plain form on every device you use. Instead, the key is protected by a passkey and only becomes usable after the device confirms that you are present.

How Passkeys Change the Login Experience

A passkey is a credential that lives on a device or in a synced password manager and is unlocked with a fingerprint, face scan or screen passcode. WebAuthn is the browser standard that lets websites and apps request these credentials without handling a password directly.

Keytr uses a passkey to encrypt the nsec and then publishes the encrypted result to Nostr relays. On a second device, you authenticate with the passkey, and the key is decrypted locally. Consider a writer who signs in on a laptop during the day and then wants to post from a phone at night. Instead of exporting a raw private key to the phone, they confirm with the passkey that is already on it.

Whether a lost passkey can be recovered depends on how each client implements credential management. It is worth checking that detail before you depend on the setup for an identity you cannot afford to lose.

Who Should Consider Keytr?

Keytr fits best in two groups. The first is developers building Nostr clients or web apps who want users to sign in without pasting a raw nsec into a form. A small team making a community app might use the integration guide to add passkey sign-in in a single afternoon of work, then test it across a few devices.

The second group is experienced Nostr users who already understand key management and want a stronger way to protect their identity. They should choose clients that have adopted the flow and read the NIP-K1 specification to understand exactly what is being stored and where.

People who simply want a finished application with a familiar interface will usually be better served by a complete Nostr client. Keytr is designed to sit underneath such a client, not to replace it.

How Do Nostr Relays Handle Encrypted Keys?

Nostr relays are servers that receive, store and forward signed messages called events. They are run by different operators, and anyone can run one. When Keytr publishes an encrypted nsec to relays, the relay operators can store that ciphertext, so the security of the design depends heavily on the encryption itself and on the passkey that unlocks it.

The intent of the design is that ciphertext on its own should not reveal the private key to a relay operator or to someone who copies the data. Still, cryptographic designs deserve careful review, and the architecture documentation is the right place to examine the assumptions being made.

For users, the practical takeaway is simple. Treat the encrypted backup as sensitive data even though it is encrypted, and keep control of the passkey that protects it.

Supported coins

The documentation mentions Nostr as the network Keytr works with, and that is the only network it is built around. Keytr is a login and key-protection tool, not a miner, so the SHA-256 hashing algorithm sometimes associated with the project does not describe what it does. Its role is to protect Nostr identities, not to handle coins or mining operations.