Custom separation character for prince cracking

[func0der]

I would like to a custom separation character for the prince cracking.

Chaining words is a common practice, they may be separated by spaces for example.

Do you see a chance for that?

[jfoug]

Should it be a character, or set of character???

My Password vs My-Password vs My:Password vs My_Password

Here the set is the 4 characters '-_ :'

[func0der]

For my usecase I basically just need one character (the whitespace). But it may be useful to have multiple, maybe even a group.

[jfoug]

I would think a 'group' would be much more powerful and useful, without too much additional coding.

[magnumripper]

Ideally this should be requested / implemented in https://github.com/hashcat/princeprocessor and then we'd merge it from upstream.

[frank-dittrich]

We might want to coordinate PRINCE mode enhancements with hashcat.

[magnumripper]

I beat you by 15 seconds @frank-dittrich 😉

[frank-dittrich]

@magnumripper

I beat you by 15 seconds @frank-dittrich

I was too busy all day, and assumed you or @jfoug would suggest that, anyway. Now I first read all the other mails, then replied. And when I pressed the [comment] button, I saw that incoming mail.

[magnumripper]

Anyway I definitely can see a use for this. Hopefully it can be added with little performance impact.

[frank-dittrich]

Also, for '-_ :' Should PRINCE mode try each separator for a combination of 2 words of given length before processing the next combination of 2 words, or should PRINCE mode just use '-' (the first separator) for all the combinations of 2 words of a given length before using the next separator?

For combinations of 3 words, should prince mode generate

one-two-three
one_two_three
one two three
one:two:three

before generating combinations like one-two_three etc.

(I know that I am "simplifying" the way PRINCE works, but I just wanted to demonstrate that there's more than one way to implement such an extension.)

There might be a several config or command line options, and it is not easy to decide which default logic might provide best results.

[jfoug]

Personally, from what I have seen in 'current' RW data, your method 1 would be best. Most RW appends are done using the same character. However, some of the notes / documentation in things like diceware, do list to use 'random' symbol characters between the simple words. If I were to use diceware, I certainly would use random character separators, since that would add additional bits for each word. If using the same characters, you only add the additional bits 1 time and none of the other separators add any additional security. But most users DO use the same separator (which is still USUALLY no separator).

So, yes, there may have to be several parameters to fully utilize this. It may even be best to provide priority:

so,

onetwothree    (is tested first)
one two three   (tested 2nd)
one-two-thee
one_two_three
and finally
one:two:three

Then there may have to be other ways to order combinations. Note, things very quickly explode (combination function), and unfortunately the combinations are not going to be uniform likely. However, figuring out which combinations are more likely is probably not going to be an easy to do task.

[func0der]

I think you are overthinking this right now, @frank-dittrich . What is talking about is basically just using one separator for the whole password. Everything else would be possible, but I think most ppl would only use one separator, like @jfoug pointed out.

The group feature would be usefull, too, but basically you could run different versions of the same command in batch for starters. That way you would only need one separator parameter for now and the rest would follow.

[magnumripper]

It turns out this is already requested in https://github.com/hashcat/princeprocessor/issues/49

[drzraf]

Wouldn't using a kind of first-pass-rule processing for separators be a less-disruptive way to implement it ?

• would not affect most of the existing pp.c code (nor keyspace generation/options/...)
• would give the flexibility of rules to define concatenation or simply limit it to a "separator-rule".

Just a quick example out of my mind: With:

[List.Rules:Separators]
SEP[@-:_\0]   # expands each combination to `<prince-elem-cnt-max - 1> * <num-separators>` concatenated combinations.

If the wordlist contains ("foo" "bar" "baz") then john --prince --prince-elem-cnt-max=3 --separator-rule:Separators --stdout would provide

• foo@bar
• foo:bar
• foobar (the \0 separator)
• `[...]
• foo@bar@baz
• foo@bar-baz
• foo@bar:baz
• [...]

Afterwards, normal existing rules pass would apply to each of them if requested by --rules.

Another possibility: Concatenate words using a truly unique character and rely exclusively on a the current rule pass assuming a rule would be able to:

1. Replace...
2. A given character...
3. At one or more position(s)...
4. By a set of characters.

Example: Combination list before rules apply:

• foo§ar
• foo§bar§baz

The rule:

[List.Rules:Separators]
RR § * [@:]

The results:

• foo@bar
• foo:bar
• foo@bar@baz
• foo@bar:baz
• foo:bar@baz
• foo:bar:baz

[solardiz]

I happen to have described a workaround in https://www.openwall.com/lists/john-users/2024/05/15/3 - start each word with a capital letter, then detect those from rules.