Fix s_ocb_done aliasing bug in decrypt path

[cyanogilvie]

I'm preparing a new release of my Tcl wrapper of libtomcrypt and hit an ocb decrypt issue while having Claude write a skill file for the package, which it tracked back to libtomcrypt and fixed here. I don't know what this project's policy is on AI generated code, but I've reviewed it and the analysis appears correct (and boils down to a single character fix). The message below and the commit were authored by Claude:

In decrypt mode (mode==1), s_ocb_done was XORing ct[x] into the checksum before writing the output. The function's parameter names are misleading (the header comment notes pt/ct really mean in/out), so in decrypt mode ct is the not-yet-written output buffer and pt is the input ciphertext. Reading from ct only worked when callers aliased the input and output buffers (in-place decryption), as the self-test does. Callers passing distinct buffers got CRYPT_OK with stat=0 — correct plaintext but failed tag verification.

Fix by reading from pt[x] (the input). Add a separate-buffer regression case to ocb_test that runs against every existing test vector and was confirmed to fail without the fix.

Checklist

• tests are added or updated

[sjaeckel]

TBH I'm not sure whether we should maybe retire OCB v1 after taking this patch? Apparently nobody's using it and it has been superseded by OCB v3 for over a decade.

Then there's the question whether we accept code written by an ML? I'm not sure about it overall, but for trivial fixes like this I don't see a good reason to decline it.

@karel-m what do you think?

[karel-m]

I agree that OCBv1 is obsolete; I am fine with removing it. I prefer that we stick to standards and here the standard is RFC 7253 (= OCBv3).

I see no issue with code produced using AI-assisted development tools such as Claude/Codex. A malicious developer can produce poor, unsafe or even stolen code with or without them.