Endianness in AES-*-CTR encryption/decryption

[alisa101rs]

I have been looking through this PR and related issues/proposals,
but I can't find any reasoning about using Ctr64LE vs Ctr64BE as a "default" implementation of AES-ddd-CTR encryption/decryption.

I have a case where I want to encrypt generated messages in vector with "AES-128-CTR" encryption
and consume it from the java backend service. I use java's Cipher.getInstance("AES/CTR/NoPadding")
to decrypt message, however the deciphered payload does not match the payload that was encrypted in the vector.

I played a little with rust's aes and ctr crates and found that Ctr64BE::<aes::Aes128> matches with the java's "AES/CTR/NoPadding", but vector is using "Ctr64LE::<aes::Aes128>.

So my question is why vector using Ctr64LE? Is java's solution incorrect?

[fuchsnj]

Hey, when this was implemented I checked an arbitrary implementation that uses AES-CTR. That one used little-endian so I made the (apparently wrong) assumption that this was typical. We certainly want to support Java, so I made an issue for fixing this: #298