this is not actually recommended, as it _technically_ does "mess up"
the sequence (1-3 zero-bytes are being encrypted along with your 1-3
remaining bytes in non-dword-sized data buffers, but those additional
encrypted zero-bytes are not being given back to you at the end).
however, in my opinion, this is quite unlikely to pose a problem for
anyone. for dealing with PSO packets, i'm pretty sure all of those end
up being dword-sized anyway, so no issue there. for encrypting and
decrypting offline quest data, the compressed bin/dat data _could_
technically be non-dword-sized (as i actually encountered today) so you
would otherwise need to pad the input data before calling crypt()
anyway. and in this case you are not going to be using that very same
Crypter instance to do any further encrypting/decrypting ... so it's
actually no problem at all.
so, to me, the convenience of having crypt() just automatically be able
to deal with any arbitrary size of data was worthwhile.
meh.
since we're doing offset/length checks regardless, calling memcmp here
instead of doing a slice comparison is at least twice as fast during
non-release builds. this is nice, as prs_compress can be quite slow
during non-release builds. and obviously during release builds, this
would be compiled down to a memcmp-equivalent anyway.
Gered