.png)
4 days ago
1
A command-line vanity (public) key generator for WireGuard. By default, it only matches the prefix of generated public keys, and not whether the search matches anywhere in the public key. The concept is based on wireguard-vanity-address, however I wanted something a little more streamlined.
- Generates compliant curve25519 private and public keys
- Configurable multi-core processing (defaults to all cores)
- Optional case sensitive searching
- Optional regex searching
- Search multiple prefixes at once
- Exit after results limit reached (defaults to 1)
- Displays probability and estimated runtime based on quick benchmark
Download the latest binary release for your system, or build from source go install github.com/axllent/wireguard-vanity-keygen@latest.
To give you a rough idea of how long it will take to generate keys, the following table lists estimated timings to find a matching key on a system that reported "Calculating speed: 230,000 calculations per second using 19 CPU cores" when it started:
| 3 chars | 0 seconds | 1 second |
| 4 chars | 9 seconds | 1 minute |
| 5 chars | 5 minutes | 1.25 hours |
| 6 chars | 4 hours | 3.5 days |
| 7 chars | 6 days | 7 months |
| 8 chars | 7 months | 38 years |
| 9 chars | 22 years | 175 years |
Note that the above timings are for finding a matching key for a single search term. Passing multiple search terms will not substantially increase the time to find any single term, but the time to find all search terms is the sum of all the estimated times. Also, increasing the limit to two (--limit 2) will double the estimated time, three will triple the time, etc.
If any search term contains numbers, the timings would fall somewhere between the case-insensitive and case-sensitive columns.
Of course, your mileage will differ, depending on the number, and speed, of your CPU cores.
Since each additional letter in a search term increases the search time exponentially, searching using a regular expression may reduce the time considerably. Here are some examples:
- .*word.* - find word anywhere in the key (word.* and .*word will also work)
- ^.{0,10}word - find word anywhere in the first 10 letters of the key
- word1.*word2 - find two words, anywhere in the key
- ^[s5][o0][ll]ar - find 'solar', or the visually similar 's01ar`, at the beginning of the key
- ^(best|next)[/+] - find 'best', or the 'next' best, at the beginning of the key, with / or + as a delimiter
A good guide on Go's regular expression syntax is at https://pkg.go.dev/regexp/syntax.
To include a literal + in your regular expression, preface it with a backslash: ^ex\+.
NOTE: If your search term contains shell metacharacters, such as |, or ^, you will need to quote it. On Windows, you must use double quotes. For example: "^(a|b)".
NOTE: Complex regular expressions, such as those using escape sequences, flags, or character classes, may never match a key. To avoid that, consider testing your regex using a tool such as this one on The Go Playground, or the same tool on goplay.tools.
Valid characters include A-Z, a-z, 0-9, / and +. There are no other characters in a hash.
You can also use regex expressions to search.
With case-insensitive searches (default), a-z have the chance of matching both uppercase and lowercase. A search for "cat" can match Cat, cAT etc.
They are not (and cannot be) accurate. Keys are completely randomly generated, and the estimate is based on a law of averages. For instance, you could find a match for a one in a billion chance on the very first hit, or it could take you 5 billion attempts. It will however give you an indication based on your CPU speed, word count, case sensitivity, and use of numbers or characters.
You don't. I wrote it because I run a WireGuard server, which does not provide any reference as to who the key belongs to (wg on the server). Using vanity keys, I can at least identify connections. I also wanted to learn more about multi-core processing in Golang.
