Vanity keygen vulnerability

When using the Vanity keypair generator, runs that generate multiple keypairs are at risk. For fast generation of subsequent keys, the generator falls back to the use of a SHA hash call instead of true random candidates. The original seed is randomly generated, but then the subsequent generations are done using a (deterministic) hash function, which is faster than seeding bytes from randomness oracles, but it is predictable.

Imagine you generate three keypairs with a pubkey starting with 111 using this generator in the same run. Anyone who knows you've used this generator to do your generation work knows to pick any of the pubkeys and start generating the candidate chain that Vanity would generate. If you're lucky, you pick the right keypair immediately and the other two keypairs are the next two matches that Vanity will find for you. This is all caused by the fact that Vanity does not change seeds when it finds a match; it simply keeps generating in the same predictable chain. Usually, this type of chain is impossible to jump into because its starting seed is random, but the other keypairs in the same chain give a free look into one of the seeds preceding the generation of the latter keypairs.

Relevant code explanation:

• Random seed initialization happens here
• Next-seed generation then uses SHA hashing to prepare the next seed. This establishes that there is a predictable generation chain
• Saving a matched keypair from the filter simply reports the result and does not reset the seed to a truly random seed, causing the random chain to persist and causing subsequent generations on the same threads to be in the same predictable generation chains

This research was performed with AI assistance.