till_key_exposure
WHAT KEY MATERIAL IS ON THIS DISK, AND WHAT STILL HOLDS AN OLD COPY OF IT? The companion to till_seed_exposure, and it exists because a real theft happened without the phrase ever being written down: the key was exfiltrated. The trap is that a secp256k1 private key is 64 hex characters and so is every SHA-256 hash, git object id and transaction hash in a saved response, so the value SHAPE carries almost no information. Two things do: STRUCTURE (a Web3 Secret Storage keystore has version 3 and a crypto member with ciphertext, kdf and mac — nothing else looks like that, and finding one is not an exposure but an encrypted wallet whose strength is its password) and THE LABEL (cleartext keys are named by what needs them, so PRIVATE_KEY matches and PRIVATE_KEY_HASH is rejected as a digest). RETAINED COPIES are what people miss: ROTATING A SECRET DOES NOT REMOVE IT FROM THE DISK, because editor history, session caches and backup folders keep snapshots of what the file used to say — on the machine this was built for, one .env holding three named keys had eighteen previous versions still readable, and the folder had been copied into a keep-across-the-reformat backup. Also reports browser wallet vaults by PRESENCE only, nothing opened or parsed, because that is how a key leaves a machine when it was never in a text file. Never outputs key material, not even a prefix: four bytes narrow a brute force. Never decrypts, never derives an address.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | directories to scan; defaults to Documents, Desktop and Downloads |