Onionmine: security of vanity address generation

The Vanity Addresses page in the Community Documentation already points both the advantages and disadvantages of using mined Onion Service addresses, from the usability perspective.

But what to say about the security implications of this practice? Is it really safe? Does it weaken the crypto?

Safety of the mining algorithm

While it has been claimed that using Vanity addresses reduce the entropy in the keys, making them easier to crack, it is reported to be safe as long as the generation procedure is well implemented.

Although we lack a formal proof for that, an argument for the safety of this procedure relies in the fact that the general algorithm for mining addresses involves first generating a key pair at random, then adding fixed numbers to both the public and private counterparts until a criteria is met -- like until a base32 encoded/serialized public key matches a regular expression, for instance when the .onion address begins with a given string.

After this procedure, the key is still random from the point of view of the cryptosystem, meaning that it would still require the same brute force attacks needed to break non-mined .onion addresses.

So any differences in entropy that might exist in the based32 .onion encoding/serialization of the public key seems not to map in reductions of the brute force search space.

Safety of the mining implementation

Another thing to consider is whether the mining tool is well implemented and does not leak information allowing attackers to regenerate related keys.

Onionmine relies on mkp224o as the key generation tool, which has some optimization flags that can have security implications if not carefully used:

./onionmine mkp224o --help
[...]

  -p PASSPHRASE         use passphrase to initialize the random seed with.
  -P                    same as -p, but takes passphrase from PASSPHRASE
                        environment variable.
  --checkpoint filename
                        load/save checkpoint of progress to specified file
                        (requires passphrase).
  --skipnear            skip near passphrase keys; you probably want this
                        because of improved safety unless you're trying to
                        regenerate an old key; possible future default.
  --warnnear            print warning about passphrase key being near another
                        (safety hazard); prefer --skipnear to this unless
                        you're regenerating an old key.

These flags can be passed to mkp224o through the MKP224O_RUN_FLAGS Onionmine configuration, and the implications are explained below.

Using a pre-generated passphrase

Supplying a pre-generated random passphrase for mkp224o allows the use of a checkpoint file (through --checkpoint), in order to resume a mining operation between runs (or even after a system reboot).

But if this passphrase is shared between mining pools, keys from distinct services can be correlated.

Also, this passphrase should never be made public, and preferably erased after the mining is concluded and an address is picked.

Supplying a passphrase to mkp224o

Never share pre-generated passphrases across mining pools.

Each pre-generated passphrases should be used only to generate a single keypair.

Never make the pre-generated passphrase public.

Wipe the pre-generated passphrase once you have chosen a generated address.

This passphrase is incremented when generating keys. Recently, mkp224o got a new --skipnear option that improves passphrase usage by avoiding similar passphrases to be used when this incrementing happens.

Always use --skipnear

Make sure to always pass --skipnear when invoking mkp224o.

This is the default on Onionmine since version 1.0.0 (2025-03-20).

Correlation between generated keys

Another concern is whether the generated public keys are correlated between themselves. If so, and the correlation is high enough, then the knowledge of more than one public key could in principle increase the chances of a successful brute force attack.

Does the odds are high enough for that to be a concern? It does not seem to be the case but, to be on the safe side, never make public more than one generated address from the same mining pool.

Protect your mining pool

To be on the safe side, when mining Onion Service addresses, don't share publicly more than a single generated address, to avoid disclosing any existing correlation between them.

Share only the address you choose for your service.

Wiping what's not used

As a final tip, it's good operational security to:

1. Backup the chosen generated key pair in a safer place (like using encrypted backups).
2. Check that the backup works.
3. Then wipe the mining pool right after.

Backing up keys and wiping the mining pool

After generating an Onion Service address, consider doing an encrypted backup of the generated keypair, checking that this backup works and them wipe the mining pool.

Onionmine has a wipe-pool command to do this final wipe.