Thanks. Yes, in the new kernel, the association data passing in to the driver, the last 8 bytes of data should be excluded in the driver. The conversion from rfc4309 test vectors defined in the testmgr.h should drop the last 8 bytes of data before passing to the openSSL API as association data. After I did that, things match.
-----Original Message----- From: Harsh Jain [mailto:harshjain.p...@gmail.com] Sent: Friday, June 9, 2017 2:31 AM To: Che-Min Hsieh <chem...@qti.qualcomm.com> Cc: linux-crypto@vger.kernel.org; Zhen Kong <zk...@quicinc.com>; Dan Bronstein <dbron...@qti.qualcomm.com> Subject: Re: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors? On Wed, Jun 7, 2017 at 7:27 PM, Che-Min Hsieh <chem...@qti.qualcomm.com> wrote: > Rfc4309 test vectors in testmgr.h have gone through major changes from linux3 > to linux4. > In linux 4.4, linux4.9, there are vectors as such > > 23194 static struct aead_testvec aes_ccm_rfc4309_enc_tv_template[] = { > 23195 { /* Generated using Crypto++ */ > 23196 .key = zeroed_string, > 23197 .klen = 19, > 23198 .iv = zeroed_string, > 23199 .input = zeroed_string, > 23200 .ilen = 16, > 23201 .assoc = zeroed_string, > 23202 .alen = 16, > 23203 .result = "\x2E\x9A\xCA\x6B\xDA\x54\xFC\x6F" > 23204 "\x12\x50\xE8\xDE\x81\x3C\x63\x08" > 23205 "\x1A\x22\xBA\x75\xEE\xD4\xD5\xB5" > 23206 "\x27\x50\x01\xAC\x03\x33\x39\xFB", > 23207 .rlen = 32, > > > I have a test program using open ssl API (-l crypto), and run on Ubuntu Linux > PC, I get the following test result: > > 2e 9a ca 6b da 54 fc 6f 12 50 e8 de 81 3c 63 08 fb 64 91 b4 dd dc bf > 5d fd 67 e3 a2 f8 7c 0e 6c > The first part of encrypted text is correct. But MAC is not the > same. > > My program is as the following: > > void ccmTest() > { > /* Initialization */ > EVP_CIPHER_CTX ctx; > EVP_CIPHER_CTX *cryptCtx = &ctx; > EVP_CIPHER_CTX_init(cryptCtx); > int i; > > unsigned char P[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; > int Psize = sizeof(P); > unsigned char K[16] = {0}; > unsigned char N[11] = {0}; > unsigned char A[16] = {0}; > unsigned char CT[128]; > > int Nsize = 11; > int Tsize = 16; > > // Initialize the context with the alg only > EVP_EncryptInit(cryptCtx, EVP_aes_128_ccm(), 0, 0); > > // Set nonce and tag sizes > EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_IVLEN, Nsize, 0); > EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_TAG, Tsize, 0); > > // Finally set the key and the nonce > EVP_EncryptInit(cryptCtx, 0, K, N); > > // Tell the alg we will encrypt Psize bytes > int outl = 0; > EVP_EncryptUpdate(cryptCtx, 0, &outl, 0, sizeof(P)); > // Add the AAD > EVP_EncryptUpdate(cryptCtx, 0, &outl, A, sizeof(A)); > // Now we encrypt the data in P, placing the output in CT > EVP_EncryptUpdate(cryptCtx, CT, &outl, P, Psize); > EVP_EncryptFinal(cryptCtx, &CT[outl], &outl); > // Append the tag to the end of the encrypted output > EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_GET_TAG, Tsize, &CT[Psize]); > hexdump(CT, Tsize+Psize); > } > > > I run "insmod tcrypt.ko mode=45" rfc4309 test with Qualcomm crypto hardware > on Linux4.4. The test fails. The generated output is the same as my openSSL > test application in 1. Older kernel driver also includes IV in Authentication data. Thats why MAC is wrong . 4.4 kernel crypto drivers don't need to include IV in authentication data. Updating driver not to include IV string in authentication data for latest kernels should work. > > My test application runs on Ubuntu with linux 3.10 rfc4309 test vector, and > generated MAC as expected from test vectors. Qualcomm crypto hardware runs > "insmod tcrypt.ko mode=45" successfully with linux 3.10. > > I am suspicious about the test vectors of 4.4. Can someone verify the Linux > 4.4 rfc4309 test vectors with his/her openSSL application on PC? > > Chemin
