Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: Crypto providers not updating cipher state when 1 block plaintext
 is encrypted
X-RT-Original-Encoding: iso-8859-1
Content-Length: 2253

It appears that the builtin and openssl AES-CTS crypto providers (for
example src/lib/crypto/openssl/enc_provider/aes.c:krb5int_aes_encrypt())
are not properly updating the ivec/cipher state argument when there is
just one block of plaintext to encrypt.  For example in
src/lib/crypto/crypto_tests/aes-test.c I modified vk_test_1() to print
out the IV used for each encrypt like so:

static void vk_test_1(int len, krb5_enctype etype)
{
    int i;

    enc_key.length = len;
    enc_key.enctype = etype;
    printf("\nKEYSIZE=%d\n\n", len * 8);
    memset(plain, 0, sizeof(plain));
    hexdump("PT", plain, 16);
    for (i = 0; i < len * 8; i++) {
        memset(key, 0, len);
        set_bit(key, i);
        printf("\nI=%d\n", i+1);
        hexdump("KEY", key, len);
        hexdump("IV", ivec.data, ivec.length); <<<<<<<<<<<<<<<<<
        enc();
        hexdump("CT", cipher, 16);
    }
    printf("\n==========\n");
}

(you may want to add this mod to that test program and regenerate
src/lib/crypto/crypto_tests/expect-vk.txt)

(Note that running aes-test -k ends up calling vk_test_1() which
repeatedly encrypts one block of plaintext using:

krb5int_aes_encrypt(k, &ivec, &iov, 1);)

When I run aes-test -k with this mod using the openssl crypto provider I
see:

KEYSIZE=128

PT=00000000000000000000000000000000

I=1
KEY=80000000000000000000000000000000
IV=00000000000000000000000000000000
CT=0EDD33D3C621E546455BD8BA1418BEC8

I=2
KEY=40000000000000000000000000000000
IV=00000000000000000000000000000000
CT=C0CC0C5DA5BD63ACD44A80774FAD5222

I=3
KEY=20000000000000000000000000000000
IV=00000000000000000000000000000000
CT=2F0B4B71BC77851B9CA56D42EB8FF080

etc... The IV is always 0 which is which is its initial value but my
understanding is that if it is passed in, as it is, it should be updated
to contain the last block of ciphertext.  I believe the builtin crypto
provider suffers from the same problem.  Other enctypes should also be
checked to see if they suffer from the same issue.

Be aware that the baseline test vector file,
src/lib/crypto/crypto_tests/expect-vk.txt, will need to be updated when
this issue is fixed.

Lastly, it would be good to have a crypto test using chained cipher
state for both 1 and > 1 block plaintext tests.