Our first full algorithm PR since we went OSS. Hurray!

... And it looks pretty good :)

Thanks :)

I forgot to mention that I implemented the input format the same I did in john the ripper. So that full compatibility either side ;)

Btw, is this somehow related to: #81 ?

Yes, it is (look at first post :-p )

TGS-REP == AP-REQ concerning ciphered part and as it is name krb5tgs in john, I named it that way

Nicely done, this is ok to merge

PR Merged, many thanks! Can we close #81 ?

Yes!

Wait, if the function returns 0, then it's not cracked. Therefire I think the code, as it is, is fine. There's no need for extra checks with 12 bytes required.

Oh wait, maybe that's what the confusion is coming from:

if (((out[2] & 0xff00ffff) != 0x30008163) && ((out[2] & 0x0000ffff) != 0x00008263)) return 0;

didn't you mean:

if (((out[1] & 0xff00ffff) != 0x30008163) || ((out[2] & 0x0000ffff) != 0x00008263)) return 0;

?

Also note the changed element number! Because if not, then there's actually only 5 bytes for check

Yeah it's a bit hard to read. Here's the JtR CPU code (for accepting, not rejecting)

if (((!memcmp(ddata + 8, "\x63\x82", 2)) && (!memcmp(ddata + 16, "\xA0\x07\x03\x05", 4)))
    ||
    ((!memcmp(ddata + 8, "\x63\x81", 2)) && (!memcmp(ddata + 16, "\x03\x05\x00", 3))))
{
    /* check the checksum to be sure */
    (...)
}

So worst case it's 5 bytes, best case is 6 bytes. That's far too small.

Indeed it is a bit hard to read, the first line is to check if any of first 16bytes contains headers. This was to avoid to compute next 16bytes and increase performances.

But we have the case that "header 1" goes with "footer 2" and would say "good boy" whereas it should not, so we have to add the last check to avoir false positives :)

But we have the case that "header 1" goes with "footer 2" and would say "good boy"

That can be avoided but we'd still only test five bytes worst case. It's pretty clear in the JtR code.

Yes, this will be fixed tomorrow 👍