Clean up and/or unify kerberos formats

[magnumripper]

Our kerberos support is a mess, in that some CPU formats support all of etypes 17, 18 and 23 (with very different speeds) whereas some OpenCL formats only support one (etype 23) or two (etypes 17/18), and are called eg. krb5pa-md5 (for etype 23 a.k.a rc4-hmac) or (worse) krb5pa-sha1-opencl or krb5asrep-aes-opencl - both are actually for etype 17/18 a.k.a aes-cts-hmac-sha1-96. Their names got to be confusing to end users.

I just whipped up formats for TGS-REP etype 17/18 and dubbed them krb5tgs-sha1[-opencl] for now, but we should amend the names and probably also clean up/unify the code: I noticed that PA, AS-REP and TGS-REP are nearly identical algorithms for a particular etype (also, etypes 17/18 are the same except for AES key length).

Ignoring backwards compatibility, we should ideally have a single CPU format for Kerberos etype 23, handling all the variants (eg. PA, AS-REP, TGS-REP) for that algorithm, and a corresponding OpenCL format of course. Then another set of formats for etypes 17/18 in the same manner.

Then again, if we separate stuff why not also separate etype 17 from etype 18 (which is half as fast due to twice the PBKDF2 output size). Or the other way round - support all algos in a single kerberos format (with etype as a cost). The last option is probably best for many end users but etype 23 is not only very different in algo and speed - it's also using UTF-16, so code can get hairy and/or suboptimal. Our current krb5asrep format does that (but only the CPU version).

[magnumripper]

Ignoring backwards compatibility, we should ideally have a single CPU format for Kerberos etype 23, handling all the variants (eg. PA, AS-REP, TGS-REP) for that algorithm, and a corresponding OpenCL format of course. Then another set of formats for etypes 17/18 in the same manner.

Then again, if we separate stuff why not also separate etype 17 from etype 18 (which is half as fast due to twice the PBKDF2 output size). Or the other way round - support all algos in a single kerberos format (with etype as a cost). The last option is probably best for many end users but etype 23 is not only very different in algo and speed - it's also using UTF-16, so code can get hairy and/or suboptimal. Our current krb5asrep format does that (but only the CPU version).

I'm currently considering the latter(est) option: A single "krb5" (or "kerberos5", or just "kerberos"?) CPU format for all request/reply types and etypes (quite possibly including etype 3 and IIRC we could even support the "DB" variant), and a corresponding one for OpenCL. The end user will be able to separate etypes using -cost if desired. The UTF-16 stuff isn't that much of a problem. We'll only have one cost, the etype. The req/rep type doesn't affect speed (the code paths are nearly identical, which is why I want to consolidate them). We could add the type as a second "cost" anyway, but that'd be for self-test and/or debugging purposes.

I'm also pondering a new flag (eg. 0x800) for benchmark_length, meaning "benchmark all different costs [that we have test vectors for] separately" (only considering first cost, for a start).

[solardiz]

I'm also pondering a new flag (eg. 0x800) for benchmark_length, meaning "benchmark all different costs [that we have test vectors for] separately" (only considering first cost, for a start).

I like this idea.