Bug report: AES CTR results differ from expected

[dsmouse]

I was working on cryptopals challenge, https://cryptopals.com/sets/3/challenges/18
It provided me an AES Key for CTR mode and a base64 encoded message to decrypt,
key=YELLOW SUBMARINE
nonce=0
format=64 bit unsigned little endian nonce,
64 bit little endian block count (byte count / 16)
The string: L77na/nrFsKvynd6HzOoG7GHTLXsTVu9qvY/2syLXzhPweyyMTJULu/6/kXX0KSvoOLSFQ==

The code I used to decrypt it worked, but when I used it on Cyberchief encrypted strings, it did not. I implemented behavior to work with cyberchief encrypted strings and found that the CTR was computed differently for non-zero block numbers, 00000000000000000100000000000000 for cryptopals and 00000000000000000000000000000001 for cyberchief.

What should happen
Given the key, nonce/IV, it should decrypt

• CyberChef version: cyberchief.org version

Additional context

This could legitly be two different implementations, if so the option to choose one or the other would be in order.

[zb3]

Seems like you want little-endian counters in AES CTR.. I see CyberChef uses node-forge which doesn't offer this feature so it's not simply a matter of passing different options

[zb3]

It seems an option like "CTR LE" would not even be enough since for Little Endian counters you also need to know the counter size which can vary (64 bit in your example, but node-forge uses 32-bit counters)
So this isn't any standard algorithm and IMO implementing this doesn't make any sense, practically no library does it.