Aes Encryption... missing an important piece

Question

I have a method in my static Encryption class that looks like this:

    public static byte[] EncryptString(string toEncrypt, byte[] encryptionKey)
    {
        var toEncryptBytes = Encoding.UTF8.GetBytes(toEncrypt);
        using (var provider = new AesCryptoServiceProvider())
        {
            provider.Key = encryptionKey;
            provider.Mode = CipherMode.ECB;
            provider.Padding = PaddingMode.ISO10126;
            using (var encryptor = provider.CreateEncryptor(provider.Key, provider.IV))
            {
                using (var ms = new MemoryStream())
                {
                    using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
                    {
                        cs.Write(toEncryptBytes, 0, toEncryptBytes.Length);
                        cs.FlushFinalBlock();
                    }
                    return ms.ToArray();
                }
            }
        }
    }

I have a unit test that looks like this:

    [TestMethod]
    public void EncryptStringEncryptsTest()
    {
        var toEncrypt = "My text to encrypt";
        var encryptionKey = Convert.FromBase64String("93mcgv9UBYpwgoUX0AXEaU1BqTCufPWPkFdOdoILLDA=");
        var encrypted = Encryption.EncryptString(toEncrypt, encryptionKey);

        var text = Convert.ToBase64String(encrypted);
        Assert.IsTrue(false);
    }

Every time I run this, the text value changes. I would expect it to be constant, given the same inputs. Am I wrong to expect that, or am I doing something wrong?

Define "not secure" in this context please, and if I change the mode, will I have to change the code? I almost always use hashes, so symmetric reversible encryption is something I must admit I have a weakness in. — Jeremy Holovacs, Nov 07 '11 at 18:59
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 — SLaks, Nov 07 '11 at 19:02

score 3 · Accepted Answer · answered Nov 07 '11 at 18:57

3

Your assumption is incorrect.

ISO10126 padding will append random data to pad your message to a multiple of the block size.

answered Nov 07 '11 at 18:57

SLaks

868,454
176
1,908
1,964

Just to make sure everything is understood, the last byte of the padding is not random, but it encodes the number of padding bytes (07h in the linked example). The rest of the bytes are actually not specified, they *could* be random but they don't have to be (the MS article linked is therefore slightly incorrect). Finally, if any of the bits in the padding is changed, the full last block (8 bytes for DES/3DES or 16 bytes for AES) of the cipher text will change. – Maarten Bodewes Nov 07 '11 at 19:44
Oh, and if there is only one byte of padding (the minimum), then your results will always be the same, even if random bytes are used for longer paddings. – Maarten Bodewes Nov 07 '11 at 19:51

score 1 · Answer 2 · answered Nov 07 '11 at 18:58

1

You are using random padding bytes, per ISO10126. So the results will not be the same each time, even with all inputs the same.

answered Nov 07 '11 at 18:58

David Schwartz

179,497
17
214
278

2

Funny enough, they may be the same as the implementer could use PKCS#5 padding to implement ISO10126. The bytes do not *have* to be random. In other words, the test may successfully run on the platform that created it, and fail on another. Isn't cryptography loads of fun? – Maarten Bodewes Nov 07 '11 at 19:49

Aes Encryption... missing an important piece

2 Answers2

Linked