Add krb5tgs-sha1 formats: Attacks TGS-REP for etypes 17 and 18

[magnumripper]

Also known as aes-cts-hmac-sha1-96. The existing krb5tgs formats are for etype 23 (rc4-hmac) and too different from 17/18 that it would be relevant to add this functionality to them.

Also add "cost" notion of etype for a few existing formats, and changed their benchmark to etype 17 instead of some unknown mix of etypes.

Closes #2809

[magnumripper]

See also #5315

[magnumripper]

Also add "cost" notion of etype for a few existing formats, and changed their benchmark to etype 17 instead of some unknown mix of etypes.

This inflates speed for some formats and deflates it for others - but the benchmark outputs a cost line that clarifies why.

Before:

$ ../run/john -test -form:krb5asrep
Will run 16 OpenMP threads
Benchmarking: krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x]... (16xOMP) DONE
Many salts:	4380K c/s real, 395546 c/s virtual
Only one salt:	3100K c/s real, 324677 c/s virtual

After:

$ ../run/john -test -form:krb5asrep 
Will run 16 OpenMP threads
Benchmarking: krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x]... (16xOMP) DONE
Speed for cost 1 (etype) of 17
Raw:	55945 c/s real, 3803 c/s virtual

Also:

$ ../run/john -test -form:krb5asrep -cost=18:18
Will run 16 OpenMP threads
Benchmarking: krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x]... (16xOMP) DONE
Speed for cost 1 (etype) of 18
Raw:	28529 c/s real, 1863 c/s virtual

$ ../run/john -test -form:krb5asrep -cost=23   
Will run 16 OpenMP threads
Benchmarking: krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x]... (16xOMP) DONE
Speed for cost 1 (etype) of 23
Raw:	3123K c/s real, 340774 c/s virtual

[solardiz]

Thanks. I skimmed and didn't notice anything obviously wrong/worse compared to the kind of code we had for this kind of formats before. There's much detail I can't fully review without diving into the specifics of these new formats. I don't know whether FMT_DYNA_SALT | FMT_HUGE_INPUT is right. Also, I guess we'll need to rerun the formats fuzzer sometime soon as we've got a few formats added since Aleksey's fuzzing.

[magnumripper]

Many salts:	4380K c/s real, 395546 c/s virtual
Only one salt:	3100K c/s real, 324677 c/s virtual

Raw:	3123K c/s real, 340774 c/s virtual

BTW we now don't get to see the effect of the new_keys logic for etype 23 (only) due to the change to 0x507 but it's still there of course. Perhaps etype 23 capable formats should have the many/one salts benchmark?

[solardiz]

Perhaps etype 23 capable formats should have the many/one salts benchmark?

Yes, perhaps. Or maybe we want to have separate format structs per etype, so that our all-formats benchmark includes all of these results individually - of course, then we'd want to do similar to other formats where we combined different-speed sub-formats into one.

[magnumripper]

I'll leave such changes to #5315