After 15 minutes spent trying to decipher this, I simply translated the code into Python and iterated infinitely. Turns out, this is how you perform big-endian addition without actually converting the number to little-endian. An odd way of doing it, but perhaps a compiler optimisation. It turns out they’re actually using AES_CTR, but instead of incrementing the entire counter IV, they’re only using the last 4 bytes. A little strange, but if your encrypted file is 232 16 bytes long, you have other problems to worry about.*
Not all that strange. The "counter block" is normally split into a nonce, which allows you to reuse the same key on multiple messages without generating a duplicate keystream, and a counter; an AES block is 16 bytes wide, so a 64 bit counter is more typical, but I've seen 32.
Doing that can even make sense, if you have bounded message sizes (<64 gigs) --- the larger the space you allocate for the nonce, the safer it is to generate nonces randomly, rather than using a system to remember all previous nonces to avoid collisions.
Not all that strange. The "counter block" is normally split into a nonce, which allows you to reuse the same key on multiple messages without generating a duplicate keystream, and a counter; an AES block is 16 bytes wide, so a 64 bit counter is more typical, but I've seen 32.
Doing that can even make sense, if you have bounded message sizes (<64 gigs) --- the larger the space you allocate for the nonce, the safer it is to generate nonces randomly, rather than using a system to remember all previous nonces to avoid collisions.