wireguard-vanity-keygen
wireguard-vanity-keygen copied to clipboard
Add regex support
Fixes #12.
I tried to write logic that converts regexs such as (abc|defg)
to defg
, but I gave up, as it's non-trivial. The cost/benefit is not worth it :). Instead, I just note the issue in the readme.
I'm sorry (and not to be rude...), but I'm really struggling to see the point of this functionality. Can you please explain the use-case for searching a regular expression?
Let me rephrase that: Can you please give me an example (or examples) of what someone may use a regular expression for?
Can you please give me an example (or examples) of what someone may use a regular expression for?
Certainly. Here are some examples:
-
.*word.*
- find word anywhere in the key (word.*
and.*word
also work) -
^.{0,10}word
- find word anywhere in the first 10 letters of the key (how wireguard-vanity-address currently works) -
word1.*word2
- find two words, but anywhere in the key. The first word may be the hostname, the second word could be the OS, its location, whether it's a server, or just a peer, etc. -
(word1|word2).*(word1|word2)
- find two words, but in any order, anywhere in the key (word1.*word1
will also match) -
^word[/+A-Z0-9]
- find lowercase word at beginning of key, but delimit with non-lowercase character, soword
stands out more clearly. See also https://github.com/warner/wireguard-vanity-address/issues/22 -
^[s5][o0][ll]ar
- find 'solar' or the visually similar 's01ar`, per https://github.com/warner/wireguard-vanity-address/issues/25 -
^[s5][i1][z2][a4][b86][l7][e3].*
- find 'sizable' in leet speek
Since adding each letter to the search term increasing the time exponentially, we want to give the user maximum flexibility in finding the term, or terms, they are looking for.
See also https://github.com/warner/wireguard-vanity-address/issues/23
I changed this to draft, as I think we should add some of the above to the readme, as I'm sure if you've questioned its usefulness, others will to.
Also, I think it's important to stop users from creating regex patterns that would never match. So, for example: aa$
will never match, as it's missing the =
character.
Also in main.go
, I would bypass the estimation for regex entirely as it cannot be calculated, as well as validate the regex (rather than a MustCompile()
)
if stripped != sword {
regex, err := regexp.Compile(sword)
if err != nil {
fmt.Printf("Invalid regular expression: %s\n", sword)
os.Exit(2)
}
c.RegexpMap[regex] = options.LimitResults
fmt.Printf("Cannot calculate probability for a regular expression: %s\n", sword)
} else {
c.WordMap[sword] = options.LimitResults
probability := keygen.CalculateProbability(stripped, options.CaseSensitive)
estimate64 := int64(speed) * probability
estimate := time.Duration(estimate64)
fmt.Printf("Probability for \"%s\": 1 in %s (approx %s per match)\n",
word, keygen.NumberFormat(probability), keygen.HumanizeDuration(estimate))
}
@axllent It's ready for review. Let me know your thoughts. Happy to make any changes you deem worthy.
Thanks awesome, thanks @rasa - I did some testing and it works as I'd expect :+1:
This has been merged and released in 0.0.9. I also just did a manual change to the README which resolves your other PR.
Thanks again for your hard work @rasa!