wireguard-vanity-keygen icon indicating copy to clipboard operation
wireguard-vanity-keygen copied to clipboard

Add regex support

Open rasa opened this issue 9 months ago • 4 comments

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.

rasa avatar May 10 '24 02:05 rasa

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?

axllent avatar May 10 '24 10:05 axllent

Can you please give me an example (or examples) of what someone may use a regular expression for?

Certainly. Here are some examples:

  1. .*word.* - find word anywhere in the key (word.* and .*word also work)
  2. ^.{0,10}word - find word anywhere in the first 10 letters of the key (how wireguard-vanity-address currently works)
  3. 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.
  4. (word1|word2).*(word1|word2) - find two words, but in any order, anywhere in the key (word1.*word1 will also match)
  5. ^word[/+A-Z0-9] - find lowercase word at beginning of key, but delimit with non-lowercase character, so word stands out more clearly. See also https://github.com/warner/wireguard-vanity-address/issues/22
  6. ^[s5][o0][ll]ar - find 'solar' or the visually similar 's01ar`, per https://github.com/warner/wireguard-vanity-address/issues/25
  7. ^[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

rasa avatar May 10 '24 13:05 rasa

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.

rasa avatar May 10 '24 14:05 rasa

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 avatar May 11 '24 03:05 axllent

@axllent It's ready for review. Let me know your thoughts. Happy to make any changes you deem worthy.

rasa avatar May 11 '24 17:05 rasa

Thanks awesome, thanks @rasa - I did some testing and it works as I'd expect :+1:

axllent avatar May 12 '24 03:05 axllent

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!

axllent avatar May 12 '24 04:05 axllent