nsec leak checker

Searching 40 million archived Nostr events turns up more than 16,000 private keys published in public. Having that list creates a problem: it is a list of working keys, so it cannot be published, and telling people individually looks exactly like the phishing message it invites.

Shape

NIP-90 data-vending machine, kinds 5300 and 6300

Authentication

The request signature is the proof of ownership

Answer

NIP-44 encrypted to the requester alone

Dataset

40M events from 1,079 relays, never committed

Repository

BigBrotr/nsec-leak-checker

BigBrotr/nsec-leak-checkerA Nostr DVM that checks whether your private key has been exposed in public events.Python

The problem

The finding cannot be distributed the way findings normally are. Publishing the list hands working keys to anyone who wants them. Contacting the affected accounts means sending an unsolicited message about their key security over the same protocol an attacker would use, to people who have already demonstrated they can be careless with credentials.

So the only safe shape is one where nobody is told anything: they ask, and only about themselves.

What I built

A service that answers job requests over the protocol itself, in about three hundred lines. The elegant part is that it needs no authentication mechanism at all: a request arrives as a signed Nostr event, and the author of that signature is the only pubkey it is answered about. The content is never read. You cannot ask about someone else, because asking is signing.

The reply is encrypted to the requester with NIP-44, so the relays that carry it – and anyone watching them – learn that a query happened and nothing about its answer.

The answer is also deliberately thin. It reports at most fifty events, each reduced to an identifier, a pubkey, a kind and a timestamp. It tells you where your key appeared without sending the leaked content back across the network a second time.

Hard parts

The dataset is the dangerous artifact, not the service. The index maps a pubkey to its exposed key, which means the files contain plaintext private keys, necessarily, because attributing a leaked string back to an owner requires reversing it. They are excluded from version control by rule rather than by convention, and the container mounts them read-only.

Answering without becoming a targeting oracle. Every design choice narrows what an observer learns: the query is answerable only by its own author, the response is encrypted, the log records a truncated fingerprint of the requester rather than the pubkey, and the payload is capped.