Computing GHASH for GCM when IV > 12 Bytes
Hi Stephen, I could not spot in the kernel where we are computing GHASH when the IV is bigger than 12 Bytes for GCM encryption. libkcapi and kernel appears to ignore the bytes beyond 12th byte in the IV. SO the o/p is same with iv=12 bytes or iv=128 bytes as can be seen below: jlulla@ubuntu:~/libkcapi-1.0.3/bin$ ./kcapi -x 2 -e -c "gcm(aes)" -k 88768354df414ce4097f4d357837116685beee0d93aab343576b893088256260 -i f649d375e4e896397a8a96cbb847fbf45cb54132c76baf814f4e35e9f7737f16d5cd710370f143612b46724bbdded2a26264b90a91f5ed425d08d317f49a56828fcfeb9ebe1bc53117bb4156c2e99d70b238dd9166cc05906719818022c75957d25ad9c36c93ce2626248c783e0207c35db74996f47d096c3cafe701a38154ce -a "" -p "" -l 16 output (with 128 Byte IV): cb35642763e3a112857acc7aeab15720 jlulla@ubuntu:~/libkcapi-1.0.3/bin$ ./kcapi -x 2 -e -c "gcm(aes)" -k 88768354df414ce4097f4d357837116685beee0d93aab343576b893088256260 -i f649d375e4e896397a8a96cb -a "" -p "" -l 16 output (with 12 byte IV): cb35642763e3a112857acc7aeab15720 The standard says something different as can be seen here Algorithm 4's step 2 [page 15] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf Freebsd's aes_gcm_prepare_j0() seems to be doing what is expected https://github.com/lattera/freebsd/blob/master/contrib/wpa/src/crypto/aes-gcm.c Does linux have any corresponding function? thanks Jitendra
GCM and XTS: kcapi result not matching with NIST vectors
Hi, Consider the following 2 invocations from kcapi and the results we get from it. They are not matching with the NIST vectors [links pasted below]. Could somebody please tell why that could be happening? thanks JItendra https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/gcmtestvectors.zip /gcmtestvectors/gcmEncryptExtIV192.rsp TEST 1: GCM [Keylen = 192] [IVlen = 8 bits] [PTlen = 128] [AADlen = 0] [Taglen = 128] NIST vector: Key = d4ba70cb3e8d246aa66ebfafd26266b5f08ec3a88000e770 IV = 13 PT = 0616236190652619ff51ad2775f2826e AAD = CT = 52b5f106a01d1cef4c833099ce88a354 Tag = d8acd529c97efbefb6102a4a9c3dafb2 attempt1: jlulla@ubuntu:~/libkcapi-1.0.3/bin$ ./kcapi -x 2 -e -c "gcm(aes)" -p 0616236190652619ff51ad2775f2826e -k d4ba70cb3e8d246aa66ebfafd26266b5f08ec3a88000e770 -i 13 -l 16 172e34500211d494ec35171aa488a26e65bc6a61759a974751875ab6fe27caed attempt2: jlulla@ubuntu:~/libkcapi-1.0.3/bin$ ./kcapi -x 2 -e -c "gcm(aes)" -p 0616236190652619ff51ad2775f2826e -k d4ba70cb3e8d246aa66ebfafd26266b5f08ec3a88000e770 -i 13 -a "" -l 16 172e34500211d494ec35171aa488a26e65bc6a61759a974751875ab6fe27caed attempt3: jlulla@ubuntu:~/libkcapi-1.0.3/bin$ ./kcapi -x 2 -e -c "gcm(aes)" -p 0616236190652619ff51ad2775f2826e -k d4ba70cb3e8d246aa66ebfafd26266b5f08ec3a88000e770 -i 13 -a 0 -l 16 172e34500211d494ec35171aa488a26e65bc6a61759a974751875ab6fe27caed SO the tag and the ct both not matching in all 3 attempts above. TEST 2: Similarly for XTS also we have one mismatch: https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/aes/XTSTestVectors.zip /XTSTestVectors/format tweak value input - 128 hex str/XTSGenAES256.rsp kcapi -x 1 -e -c "xts(aes)" -k 31c8152b5eddc3b8c3a005a3bbc4c005bb57058ae4a6454c166a620389eaecaea0515433574b0dd6a89496acd475ef78dcf012a47a48c319f89e931404018e15 -p 31761b6dece3e962030c01f481c5ca681386176d2ef8034c5db5aa04b613ec00 -i 6957d297dc9c9b30f6d016b016d913c5 Result from tool : 1e16b5a44274f8791508cf3dec971aa975e16c702d66f11bc1f00ede540ef82c NIST Expected Result : ae13222810bc66997bf8b57737990e481e16b5a44274f8791508cf3dec971a80
hashing bit oriented messages
Hi, the following NIST link has test vectors for SHA1/2/3. https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/secure-hashing They have test vectors for bit oriented messages also e.g. a message of 7 bits for example. [grep "Bit-Oriented" on the page, bottom of the page] Some sw implementations do support computing SHA* on such messages which are not byte aligned. e.g. libdigest-sha3-perl and libdigest-sha-perl (tried on Ubuntu) Some example runs at the bottom of this mail. I have following queries, could anybody please help me with them: 1. When would one want to compute digests on such messages eg. a 7 bit message or a 133 bit message? Any practical use case? 2. testmgr.h doesnt have tests for such messages. Does linux kernel crypto framework support it or have plans for it? 3. Does any fips certification mandate bit-oriented tests to pass ? thanks Jitendra example invocations: jlulla@ubuntu:~/Link to progs$ perl -e "print qq(1)" | sha3sum -0 -a 224 6f2fc54a6b11a6da611ed734505b9cab89eecc1dc7dd2debd27bd1c9 ^- jlulla@ubuntu:~/Link to progs$ perl -e "print qq(011)" | shasum -0 -a 256 1f7794d4b0b67d3a6edcd17aba2144a95828032f7943ed26bf0c7c7628945f48 ^- jlulla@ubuntu:~/Link to progs$ perl -e "print qq(1101110)" | shasum -0 -a 256 83e848e33f2aec12959a5de8232989ee09e7841f9f031147a651d286e8c7218e ^- perl -e "print qq(0001100)" | sha3sum -0 -a 384 b5a8cb0bf073b6b68d95cd33f5b09289670120bb931fc838b830d2592268b9e145a09088172b96eafb0093ef9a85df08 ^-
RE: RFC: Crypto API User-interface
Hi,
http://lwn.net/Articles/410848/
The following code is taken from the above page:
int main(void)
{
int opfd;
int tfmfd;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher",
.salg_name = "cbc(aes)"
};
struct msghdr msg = {};
struct cmsghdr *cmsg;
char cbuf[CMSG_SPACE(4) + CMSG_SPACE(20)];
char buf[16];
struct af_alg_iv *iv;
struct iovec iov;
int i;
tfmfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(tfmfd, (struct sockaddr *)&sa, sizeof(sa));
setsockopt(tfmfd, SOL_ALG, ALG_SET_KEY,
"\x06\xa9\x21\x40\x36\xb8\xa1\x5b"
"\x51\x2e\x03\xd5\x34\x12\x00\x06", 16);
opfd = accept(tfmfd, NULL, 0);
msg.msg_control = cbuf;
msg.msg_controllen = sizeof(cbuf);
cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_ALG;
cmsg->cmsg_type = ALG_SET_OP;
cmsg->cmsg_len = CMSG_LEN(4);
*(__u32 *)CMSG_DATA(cmsg) = ALG_OP_ENCRYPT;
cmsg = CMSG_NXTHDR(&msg, cmsg);
cmsg->cmsg_level = SOL_ALG;
cmsg->cmsg_type = ALG_SET_IV;
cmsg->cmsg_len = CMSG_LEN(20);
iv = (void *)CMSG_DATA(cmsg);
iv->ivlen = 16;
memcpy(iv->iv, "\x3d\xaf\xba\x42\x9d\x9e\xb4\x30"
"\xb4\x22\xda\x80\x2c\x9f\xac\x41", 16);
iov.iov_base = "Single block msg";
iov.iov_len = 16;
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
sendmsg(opfd, &msg, 0);
read(opfd, buf, 16);
for (i = 0; i < 16; i++) {
printf("%02x", (unsigned char)buf[i]);
}
printf("\n");
close(opfd);
close(tfmfd);
return 0;
}
Here the following small change is needed for this program to work:
memset(cbuf, 0, CMSG_SPACE(4) + CMSG_SPACE(20));
This memset is required otherwise the CMSG_NXTHDR may return a NULL
causing a seg fault in the following line:
cmsg->cmsg_level = SOL_ALG;
I have tried this on 3.3.4-5.fc17.x86_64.
Posting this as it may help people who want to use/refer this example code.
However, can somebody please point me to some more examples which use
af_alg socket (without Openssl! as the af_alg engine for openssl
(http://src.carnivore.it/users/common/af_alg/) is incomplete
supporting only aes-cbc,sha1,sha2 only as of today. No other aes
variants supported in af_alg engine.)
I am particulart wanting to know how I can compute hmac and aes-xts or
ctr modes with af_alg without having to go via openssl.
~Jitendra
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Crypto API User-interface
Hi, This is regarding the hash computation over a file with AF_ALG from user space. [without OpenSSL] The following link has the mail from Herbert with subject : "RFC: Crypto API User-interface" http://lwn.net/Articles/410848/ I was trying to take help from the code snippet he has put in his mail and I was doing the following to compute hash over a file of 16 bytes. The file contents are "123456789012345\n". I read the first 10 bytes first and computed hash over it. Then I read the next 6 bytes from the file and computed the hash and I had taken care of using the flags MSG_MORE and MSG_OOB. Following is what I am doing: 1. send(opfd, sbuf, len, MSG_MORE); 2. read(opfd, state, 20); 3. send(opfd, state, 20, MSG_OOB); 4. send(opfd, sbuf, len, MSG_MORE); 5. read(opfd, state, 20); 6. /*restore from a partial hash state */ 7. send(opfd, state, 20, MSG_OOB); 8. /* finalize */ 9. send(opfd, sbuf, 0, 0); 10. read(opfd, buf, 20); sbuf in line 1 contains: "1234567890" (the " is not part of the data, the data is plain 10 ascii bytes for 1 through 9), len is 10. the state after line 2 contains correct hash of the above data. sbuf in line 4 contains: "12345\n". Len is 6. The hash I am seeing in buf after line 10 is not correct one. Is there anything obviously wrong with the above code? I am using 2.6.39.4 kernel on rhel 6.4 (santiago) Thanks for the help! ~Jitendra -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
