Personal
nsec leak checker
A Nostr data-vending machine that checks the signing public key of a request against an exposure dataset and returns encrypted references to matching events.
The project’s recorded analysis of 40 million archived Nostr events found more than 16,000 exposed private keys. Those are results from the analyzed corpus, not a current network total. The service lets a requester check its signing public key against that dataset without republishing the leaked event content.
- Shape
- NIP-90 data-vending machine, kinds 5300 and 6300
- Authentication
- Request signature proves possession of the signing key
- Answer
- NIP-44 encrypted to the requesting public key
- Dataset
- 40M events from 1,079 relays, never committed
- Repository
- BigBrotr/nsec-leak-checker
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 key security over the same protocol an attacker could use. Users need a way to distinguish a legitimate exposure check from an attempt to obtain their credentials.
This service takes requests instead of sending unsolicited notifications, and binds each query to the public key that signed it.
16,000+
exposed keys found
40M
events searched
What I built
Each request is a signed Nostr event, and the service answers only about its signing public key. The request content is not used to select another identity. This proves possession of the private key, not exclusive ownership: anyone holding an exposed private key can make the same request.
Replies are encrypted with NIP-44. This hides their content from observers without the key, but does not protect them from someone who already holds the exposed private key. The protocol’s security limits explicitly exclude forward secrecy and security after key compromise.
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
Handling a dataset that contains secrets. The recorded dataset maps public keys to exposed private keys and therefore contains plaintext secrets. Those files are excluded from version control and mounted read-only. A public key can be derived when a leaked key is ingested; retaining the private key is a property of this dataset, not a cryptographic requirement for answering an exposure query.
Limiting what a query discloses. The query is restricted to its signing key, the response is encrypted, the log records a truncated fingerprint of the requester rather than the pubkey, and the payload is capped. These measures reduce disclosure without resolving the underlying key compromise.