ReferenceTestCbc test fails if key size is not 16

[Havunen]

Hi,

I find this project very interesting.
Do you know why

        [Fact]
        public void ReferenceTestCbc()
        {
            var r = new Random(42);
            var bytes = new byte[DataSize];
            var key = new byte[16]; // Change this to 32 ? fails
            var iv = new byte[16];
            r.NextBytes(bytes);
            r.NextBytes(key);
            r.NextBytes(iv);

            var managed = new AesManaged {Key = key, IV = iv, Mode = CipherMode.CBC, Padding = PaddingMode.PKCS7};
            var managedResult = managed.CreateEncryptor().TransformFinalBlock(bytes, 0, bytes.Length);

            var niResult = new byte[DataSize];
            Aes.EncryptCbc(bytes, niResult, iv, new Aes128Key(key), PaddingMode.PKCS7);

            Assert.Equal(managedResult, niResult);
        }

EncryptCbc converts to different value than AesManaged when key size is not 16?

[Havunen]

There is also some sort of an issue when BlockSize is larger than input byte array length.
AESManaged handles that but This lib fails

[Havunen]

Or maybe this is related to PaddingMode.PKCS7

[Havunen]

Do you have any plans for implementing rijndael algorithm?

[tkp1n]

Have you tried using Aes256Key for your 32 byte key (32 bytes = 256bit)?:

Aes.EncryptCbc(bytes, niResult, iv, new Aes256Key(key), PaddingMode.PKCS7);

The constructor of the AesXXXKey classes should throw if the array size is not as expected... I'll fix this in the future once I find time for it. Feel free to open a PR for this, if you like :)

Please be aware that this project is merely a playground for the runtime intrinsics and not intended for production use!

[Havunen]

Have you tried using Aes256Key for your 32 byte key (32 bytes = 256bit)?:

Yeah I tried, but its possible I did something wrong.

Please be aware that this project is merely a playground for the runtime intrinsics and not intended for production use!

Yeah we have very specific use of aes encryption and I wanted to see how much performance gain there could be If algorithm was implemented using runtime intrinsics. Basically we do a lot tranformFinalBlock calls and the security does not matter, but it needs to give same result as AES managed instance

[tkp1n]

I just double-checked. There is an issue currently with the different paddings. I'll look into it

[tkp1n]

Applying padding is fixed in 4b4c42f.

As stated in the readme, removing and verifying padding is not implemented. You'd have to provide oversized buffers for the plaintext after decryption including the padding and remove/verify it manually. Or, better yet, add this missing functionality in a PR 😉

Let me know if this fixed your issue.