seekrit

hash-grinding entropy generator for Bitcoin secret keys

download (binary, no build required)

https://git.smesh.lol/seekrit/raw/seekrit

built for glibc linux (amd64). works on any current desktop/server distro, and inside WSL2 on windows.

wget https://git.smesh.lol/seekrit/raw/seekrit
chmod +x seekrit

build from source

go build -o seekrit .

copy the binary somewhere in $PATH, or go run . in place.

usage

./seekrit

let it run. the longer it runs, the more entropy. hit ctrl-c to stop. output printed to stdout:

hex: c212dfa9b3f7bb25b36949f96f014270c89f83a02f6484b03bc75ef19d97618b
WIF (uncompressed): 5JHeosLHoxDvj88PN1oQ7bxm14Vk3ZRqvdVvKB7Kpw48q6qkv8i
WIF (compressed):   L1qMqmjcaxfyPQBpnBMwRCuRNiYhVaPVDcZ3a3WkRpPEigyatcne

theory

on launch, seekrit seeds a SHA256 hash with the current nanosecond timestamp. it then loops: hash the output of the previous step. no sleep, no yield, no blocking.

the entropy does not come from the seed - the timestamp alone provides maybe 30 bits. the entropy comes from the fact that the number of hash iterations before ctrl-c is fundamentally unpredictable. an attacker who knows the exact start time and your CPU model still cannot determine the loop count. a one-second difference in stopping time translates to millions of iterations. an hour translates to billions.

each iteration is a one-way compression function. truncating the chain at an unknown point is equivalent to selecting uniformly from an astronomically large set of deterministic outputs. the adversary cannot replay the chain forward from the seed because doing so would require guessing the loop count, which is the secret.

security

this program generates secrets in RAM on the machine that runs it. the security of the generated key depends entirely on the security of that machine:

• near field sensors: EM emanations from the CPU and memory bus can leak data. assume any machine that has been in proximity to an adversary is compromised.
• airgap: generate on a computer that has never been and will never be connected to a network.
• live USB: boot from a known-clean live USB image. do not generate keys on an OS that stores state across reboots.
• FARADAY BAG: no, really, but put the phone over there holy shit.

if an adversary has physical or remote access to the machine at the time of generation, the key is compromised. no amount of hash grinding fixes that.