* Test AEAD/authenc algorithms from userspace
@ 2016-05-31 7:01 Harsh Jain
2016-05-31 7:05 ` Stephan Mueller
0 siblings, 1 reply; 13+ messages in thread
From: Harsh Jain @ 2016-05-31 7:01 UTC (permalink / raw)
To: linux-crypto
Hi All,
How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
userspace program.I check libkcapi library. It has test programs for
GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
Which of them is supported in crypto framework.
1) Encrypt-then-MAC (EtM)
The plaintext is first encrypted, then a MAC is produced based on
the resulting ciphertext. The ciphertext and its MAC are sent
together.
2) Encrypt-and-MAC (E&M)
A MAC is produced based on the plaintext, and the plaintext is
encrypted without the MAC. The plaintext's MAC and the ciphertext are
sent together.
3) MAC-then-Encrypt (MtE)
A MAC is produced based on the plaintext, then the plaintext and
MAC are together encrypted to produce a ciphertext based on both. The
ciphertext (containing an encrypted MAC) is sent.
Regards
Harsh Jain
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 7:01 Test AEAD/authenc algorithms from userspace Harsh Jain @ 2016-05-31 7:05 ` Stephan Mueller 2016-05-31 8:40 ` Harsh Jain 2016-12-19 10:38 ` Harsh Jain 0 siblings, 2 replies; 13+ messages in thread From: Stephan Mueller @ 2016-05-31 7:05 UTC (permalink / raw) To: Harsh Jain; +Cc: linux-crypto Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: Hi Harsh, > Hi All, > > How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from > userspace program.I check libkcapi library. It has test programs for > GCM/CCM. There are 3 types of approaches to Authenticated Encryption, > Which of them is supported in crypto framework. > > 1) Encrypt-then-MAC (EtM) > The plaintext is first encrypted, then a MAC is produced based on > the resulting ciphertext. The ciphertext and its MAC are sent > together. > 2) Encrypt-and-MAC (E&M) > A MAC is produced based on the plaintext, and the plaintext is > encrypted without the MAC. The plaintext's MAC and the ciphertext are > sent together. > > 3) MAC-then-Encrypt (MtE) > A MAC is produced based on the plaintext, then the plaintext and > MAC are together encrypted to produce a ciphertext based on both. The > ciphertext (containing an encrypted MAC) is sent. The cipher types you mention refer to the implementation of authenc(). IIRC, authenc implements EtM as this is mandated by IPSEC. When you use libkcapi, you should simply be able to use your cipher name with the AEAD API. I.e. use the examples you see for CCM or GCM and use those with the chosen authenc() cipher. Do you experience any issues? Ciao Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 7:05 ` Stephan Mueller @ 2016-05-31 8:40 ` Harsh Jain 2016-05-31 8:59 ` Stephan Mueller 2016-12-19 10:38 ` Harsh Jain 1 sibling, 1 reply; 13+ messages in thread From: Harsh Jain @ 2016-05-31 8:40 UTC (permalink / raw) To: Stephan Mueller; +Cc: linux-crypto Hi, You means to say like this ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44 It gives following error with kernel 4.5.2 Symmetric cipher setkey failed Failed to invoke testing Regards Harsh Jain On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: > > Hi Harsh, > >> Hi All, >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from >> userspace program.I check libkcapi library. It has test programs for >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, >> Which of them is supported in crypto framework. >> >> 1) Encrypt-then-MAC (EtM) >> The plaintext is first encrypted, then a MAC is produced based on >> the resulting ciphertext. The ciphertext and its MAC are sent >> together. >> 2) Encrypt-and-MAC (E&M) >> A MAC is produced based on the plaintext, and the plaintext is >> encrypted without the MAC. The plaintext's MAC and the ciphertext are >> sent together. >> >> 3) MAC-then-Encrypt (MtE) >> A MAC is produced based on the plaintext, then the plaintext and >> MAC are together encrypted to produce a ciphertext based on both. The >> ciphertext (containing an encrypted MAC) is sent. > > The cipher types you mention refer to the implementation of authenc(). IIRC, > authenc implements EtM as this is mandated by IPSEC. > > When you use libkcapi, you should simply be able to use your cipher name with > the AEAD API. I.e. use the examples you see for CCM or GCM and use those with > the chosen authenc() cipher. Do you experience any issues? > > Ciao > Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 8:40 ` Harsh Jain @ 2016-05-31 8:59 ` Stephan Mueller 2016-05-31 9:15 ` Harsh Jain 0 siblings, 1 reply; 13+ messages in thread From: Stephan Mueller @ 2016-05-31 8:59 UTC (permalink / raw) To: Harsh Jain; +Cc: linux-crypto Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain: Hi Harsh, > Hi, > > You means to say like this > > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p > 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k > 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i > 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 > -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44 > > It gives following error with kernel 4.5.2 > Symmetric cipher setkey failed > Failed to invoke testing > Please see testmgr.h for usage (especially the key encoding): invocation: ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p 53696e676c6520626c6f636b206d7367 -k 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b512e03d534120006 -i 3dafba429d9eb430b422da802c9fac41 -a 3dafba429d9eb430b422da802c9fac41 -l 20 return: e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206 This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1). Note, the input string of "Single block msg" was converted to hex 53696e676c6520626c6f636b206d7367 as my tool always treats all input data as hex data. > > > Regards > Harsh Jain > > On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> wrote: > > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: > > > > Hi Harsh, > > > >> Hi All, > >> > >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from > >> userspace program.I check libkcapi library. It has test programs for > >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, > >> Which of them is supported in crypto framework. > >> > >> 1) Encrypt-then-MAC (EtM) > >> > >> The plaintext is first encrypted, then a MAC is produced based on > >> > >> the resulting ciphertext. The ciphertext and its MAC are sent > >> together. > >> 2) Encrypt-and-MAC (E&M) > >> > >> A MAC is produced based on the plaintext, and the plaintext is > >> > >> encrypted without the MAC. The plaintext's MAC and the ciphertext are > >> sent together. > >> > >> 3) MAC-then-Encrypt (MtE) > >> > >> A MAC is produced based on the plaintext, then the plaintext and > >> > >> MAC are together encrypted to produce a ciphertext based on both. The > >> ciphertext (containing an encrypted MAC) is sent. > > > > The cipher types you mention refer to the implementation of authenc(). > > IIRC, authenc implements EtM as this is mandated by IPSEC. > > > > When you use libkcapi, you should simply be able to use your cipher name > > with the AEAD API. I.e. use the examples you see for CCM or GCM and use > > those with the chosen authenc() cipher. Do you experience any issues? > > > > Ciao > > Stephan Ciao Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 8:59 ` Stephan Mueller @ 2016-05-31 9:15 ` Harsh Jain 2016-05-31 9:21 ` Stephan Mueller 0 siblings, 1 reply; 13+ messages in thread From: Harsh Jain @ 2016-05-31 9:15 UTC (permalink / raw) To: Stephan Mueller; +Cc: linux-crypto Hi, Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add some switch cases in tool to test digest and finup path of crypto driver. Current implementation triggers only init/update/final. Regards Harsh Jain On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain: > > Hi Harsh, > >> Hi, >> >> You means to say like this >> >> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p >> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k >> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i >> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 >> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44 >> >> It gives following error with kernel 4.5.2 >> Symmetric cipher setkey failed >> Failed to invoke testing >> > > Please see testmgr.h for usage (especially the key encoding): > > invocation: > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p > 53696e676c6520626c6f636b206d7367 -k > 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b512e03d534120006 > -i 3dafba429d9eb430b422da802c9fac41 -a 3dafba429d9eb430b422da802c9fac41 -l 20 > > return: > e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206 > > This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1). > Note, the input string of "Single block msg" was converted to hex > 53696e676c6520626c6f636b206d7367 as my tool always treats all input data as > hex data. > >> >> >> Regards >> Harsh Jain >> >> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> > wrote: >> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: >> > >> > Hi Harsh, >> > >> >> Hi All, >> >> >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from >> >> userspace program.I check libkcapi library. It has test programs for >> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, >> >> Which of them is supported in crypto framework. >> >> >> >> 1) Encrypt-then-MAC (EtM) >> >> >> >> The plaintext is first encrypted, then a MAC is produced based on >> >> >> >> the resulting ciphertext. The ciphertext and its MAC are sent >> >> together. >> >> 2) Encrypt-and-MAC (E&M) >> >> >> >> A MAC is produced based on the plaintext, and the plaintext is >> >> >> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are >> >> sent together. >> >> >> >> 3) MAC-then-Encrypt (MtE) >> >> >> >> A MAC is produced based on the plaintext, then the plaintext and >> >> >> >> MAC are together encrypted to produce a ciphertext based on both. The >> >> ciphertext (containing an encrypted MAC) is sent. >> > >> > The cipher types you mention refer to the implementation of authenc(). >> > IIRC, authenc implements EtM as this is mandated by IPSEC. >> > >> > When you use libkcapi, you should simply be able to use your cipher name >> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use >> > those with the chosen authenc() cipher. Do you experience any issues? >> > >> > Ciao >> > Stephan > > > Ciao > Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 9:15 ` Harsh Jain @ 2016-05-31 9:21 ` Stephan Mueller 2016-05-31 10:58 ` Harsh Jain 0 siblings, 1 reply; 13+ messages in thread From: Stephan Mueller @ 2016-05-31 9:21 UTC (permalink / raw) To: Harsh Jain; +Cc: linux-crypto Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain: Hi Harsh, > Hi, > > Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add > some switch cases in tool to test digest and finup path of crypto > driver. Current implementation triggers only init/update/final. You mean for hashes? I guess the following is what you refer to? This logic is even found for the other cipher types (symmetric algos, AEAD ciphers). See the documentation on stream vs one-shot use cases. /** * kcapi_md_init() - initialize cipher handle * @handle: cipher handle filled during the call - output * @ciphername: kernel crypto API cipher name as specified in * /proc/crypto - input * @flags: flags specifying the type of cipher handle * * This function provides the initialization of a (keyed) message digest handle * and establishes the connection to the kernel. * * Return: 0 upon success; ENOENT - algorithm not available; * -EOPNOTSUPP - AF_ALG family not available; * -EINVAL - accept syscall failed * -ENOMEM - cipher handle cannot be allocated */ int kcapi_md_init(struct kcapi_handle **handle, const char *ciphername, uint32_t flags); /** * kcapi_md_update() - message digest update function (stream) * @handle: cipher handle - input * @buffer: holding the data to add to the message digest - input * @len: buffer length - input * * Return: 0 upon success; * < 0 in case of error */ int32_t kcapi_md_update(struct kcapi_handle *handle, const uint8_t *buffer, uint32_t len); /** * kcapi_md_final() - message digest finalization function (stream) * @handle: cipher handle - input * @buffer: filled with the message digest - output * @len: buffer length - input * * Return: size of message digest upon success; * -EIO - data cannot be obtained; * -ENOMEM - buffer is too small for the complete message digest, * the buffer is filled with the truncated message digest */ int32_t kcapi_md_final(struct kcapi_handle *handle, uint8_t *buffer, uint32_t len); The test/kcapi tool is a crude test tool that I use for my regression testing. It is not intended for anything else. > > > Regards > Harsh Jain > > On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de> wrote: > > Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain: > > > > Hi Harsh, > > > >> Hi, > >> > >> You means to say like this > >> > >> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p > >> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k > >> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i > >> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 > >> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44 > >> > >> It gives following error with kernel 4.5.2 > >> Symmetric cipher setkey failed > >> Failed to invoke testing > > > > Please see testmgr.h for usage (especially the key encoding): > > > > invocation: > > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p > > 53696e676c6520626c6f636b206d7367 -k > > 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b51 > > 2e03d534120006 -i 3dafba429d9eb430b422da802c9fac41 -a > > 3dafba429d9eb430b422da802c9fac41 -l 20 > > > > return: > > e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206 > > > > This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1). > > Note, the input string of "Single block msg" was converted to hex > > 53696e676c6520626c6f636b206d7367 as my tool always treats all input data > > as > > hex data. > > > >> Regards > >> Harsh Jain > >> > >> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> > > > > wrote: > >> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: > >> > > >> > Hi Harsh, > >> > > >> >> Hi All, > >> >> > >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from > >> >> userspace program.I check libkcapi library. It has test programs for > >> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, > >> >> Which of them is supported in crypto framework. > >> >> > >> >> 1) Encrypt-then-MAC (EtM) > >> >> > >> >> The plaintext is first encrypted, then a MAC is produced based on > >> >> > >> >> the resulting ciphertext. The ciphertext and its MAC are sent > >> >> together. > >> >> 2) Encrypt-and-MAC (E&M) > >> >> > >> >> A MAC is produced based on the plaintext, and the plaintext is > >> >> > >> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are > >> >> sent together. > >> >> > >> >> 3) MAC-then-Encrypt (MtE) > >> >> > >> >> A MAC is produced based on the plaintext, then the plaintext and > >> >> > >> >> MAC are together encrypted to produce a ciphertext based on both. The > >> >> ciphertext (containing an encrypted MAC) is sent. > >> > > >> > The cipher types you mention refer to the implementation of authenc(). > >> > IIRC, authenc implements EtM as this is mandated by IPSEC. > >> > > >> > When you use libkcapi, you should simply be able to use your cipher > >> > name > >> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use > >> > those with the chosen authenc() cipher. Do you experience any issues? > >> > > >> > Ciao > >> > Stephan > > > > Ciao > > Stephan Ciao Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 9:21 ` Stephan Mueller @ 2016-05-31 10:58 ` Harsh Jain 2016-05-31 11:05 ` Stephan Mueller 0 siblings, 1 reply; 13+ messages in thread From: Harsh Jain @ 2016-05-31 10:58 UTC (permalink / raw) To: Stephan Mueller; +Cc: linux-crypto Hi Stephen, Yes ,It's for Hash. The available API in library for hash update "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not trigger driver's digest/finup implementation. We need something like that _kcapi_common_accept() send(handle->opfd, buffer, len, 0); ==> flag = 0. It will execute digest callback of selected tfm from User Space.(init->digest) Similarly _kcapi_common_accept() send(handle->opfd, buffer, len, MSG_MORE); send(handle->opfd, buffer, len, 0); It will execute finup callback of selected tfm. (init->update->finup). In that way we can test all callbacks from userspace. In future if you feel this use case important. You can add API's to implement this. Regards Harsh Jain regards Harsh Jain regards Harsh Jain On Tue, May 31, 2016 at 2:51 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain: > > Hi Harsh, > >> Hi, >> >> Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add >> some switch cases in tool to test digest and finup path of crypto >> driver. Current implementation triggers only init/update/final. > > You mean for hashes? I guess the following is what you refer to? This logic is > even found for the other cipher types (symmetric algos, AEAD ciphers). See the > documentation on stream vs one-shot use cases. > > /** > * kcapi_md_init() - initialize cipher handle > * @handle: cipher handle filled during the call - output > * @ciphername: kernel crypto API cipher name as specified in > * /proc/crypto - input > * @flags: flags specifying the type of cipher handle > * > * This function provides the initialization of a (keyed) message digest > handle > * and establishes the connection to the kernel. > * > * Return: 0 upon success; ENOENT - algorithm not available; > * -EOPNOTSUPP - AF_ALG family not available; > * -EINVAL - accept syscall failed > * -ENOMEM - cipher handle cannot be allocated > */ > int kcapi_md_init(struct kcapi_handle **handle, const char *ciphername, > uint32_t flags); > > /** > * kcapi_md_update() - message digest update function (stream) > * @handle: cipher handle - input > * @buffer: holding the data to add to the message digest - input > * @len: buffer length - input > * > * Return: 0 upon success; > * < 0 in case of error > */ > int32_t kcapi_md_update(struct kcapi_handle *handle, > const uint8_t *buffer, uint32_t len); > > /** > * kcapi_md_final() - message digest finalization function (stream) > * @handle: cipher handle - input > * @buffer: filled with the message digest - output > * @len: buffer length - input > * > * Return: size of message digest upon success; > * -EIO - data cannot be obtained; > * -ENOMEM - buffer is too small for the complete message digest, > * the buffer is filled with the truncated message digest > */ > int32_t kcapi_md_final(struct kcapi_handle *handle, > uint8_t *buffer, uint32_t len); > > > The test/kcapi tool is a crude test tool that I use for my regression testing. > It is not intended for anything else. >> >> >> Regards >> Harsh Jain >> >> On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de> > wrote: >> > Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain: >> > >> > Hi Harsh, >> > >> >> Hi, >> >> >> >> You means to say like this >> >> >> >> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p >> >> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k >> >> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i >> >> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 >> >> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44 >> >> >> >> It gives following error with kernel 4.5.2 >> >> Symmetric cipher setkey failed >> >> Failed to invoke testing >> > >> > Please see testmgr.h for usage (especially the key encoding): >> > >> > invocation: >> > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p >> > 53696e676c6520626c6f636b206d7367 -k >> > 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b51 >> > 2e03d534120006 -i 3dafba429d9eb430b422da802c9fac41 -a >> > 3dafba429d9eb430b422da802c9fac41 -l 20 >> > >> > return: >> > e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206 >> > >> > This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1). >> > Note, the input string of "Single block msg" was converted to hex >> > 53696e676c6520626c6f636b206d7367 as my tool always treats all input data >> > as >> > hex data. >> > >> >> Regards >> >> Harsh Jain >> >> >> >> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> >> > >> > wrote: >> >> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: >> >> > >> >> > Hi Harsh, >> >> > >> >> >> Hi All, >> >> >> >> >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from >> >> >> userspace program.I check libkcapi library. It has test programs for >> >> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, >> >> >> Which of them is supported in crypto framework. >> >> >> >> >> >> 1) Encrypt-then-MAC (EtM) >> >> >> >> >> >> The plaintext is first encrypted, then a MAC is produced based on >> >> >> >> >> >> the resulting ciphertext. The ciphertext and its MAC are sent >> >> >> together. >> >> >> 2) Encrypt-and-MAC (E&M) >> >> >> >> >> >> A MAC is produced based on the plaintext, and the plaintext is >> >> >> >> >> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are >> >> >> sent together. >> >> >> >> >> >> 3) MAC-then-Encrypt (MtE) >> >> >> >> >> >> A MAC is produced based on the plaintext, then the plaintext and >> >> >> >> >> >> MAC are together encrypted to produce a ciphertext based on both. The >> >> >> ciphertext (containing an encrypted MAC) is sent. >> >> > >> >> > The cipher types you mention refer to the implementation of authenc(). >> >> > IIRC, authenc implements EtM as this is mandated by IPSEC. >> >> > >> >> > When you use libkcapi, you should simply be able to use your cipher >> >> > name >> >> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use >> >> > those with the chosen authenc() cipher. Do you experience any issues? >> >> > >> >> > Ciao >> >> > Stephan >> > >> > Ciao >> > Stephan > > > Ciao > Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 10:58 ` Harsh Jain @ 2016-05-31 11:05 ` Stephan Mueller 2016-05-31 11:52 ` Harsh Jain 0 siblings, 1 reply; 13+ messages in thread From: Stephan Mueller @ 2016-05-31 11:05 UTC (permalink / raw) To: Harsh Jain; +Cc: linux-crypto Am Dienstag, 31. Mai 2016, 16:28:14 schrieb Harsh Jain: Hi Harsh, > Hi Stephen, > > Yes ,It's for Hash. The available API in library for hash update > "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not > trigger driver's digest/finup implementation. We need something like > that > > _kcapi_common_accept() > send(handle->opfd, buffer, len, 0); ==> flag = 0. > > It will execute digest callback of selected tfm from User > Space.(init->digest) Similarly > > _kcapi_common_accept() > send(handle->opfd, buffer, len, MSG_MORE); > send(handle->opfd, buffer, len, 0); > > It will execute finup callback of selected tfm. (init->update->finup). > > In that way we can test all callbacks from userspace. In future if you > feel this use case important. You can add API's to implement this. Ok, I see that the finup code path is not exercised in the kernel by my library. Why do you think that this code path should be tested by my test code? The test code shall verify that libkcapi works fine. Ciao Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 11:05 ` Stephan Mueller @ 2016-05-31 11:52 ` Harsh Jain 2016-05-31 11:55 ` Stephan Mueller 0 siblings, 1 reply; 13+ messages in thread From: Harsh Jain @ 2016-05-31 11:52 UTC (permalink / raw) To: Stephan Mueller; +Cc: linux-crypto Hi, 1) User can use libkcapi to write program for finup/digest. 2) No, kernel test for finup (not sure). 3) We can test all callback of new hash tfm drivers added in kernel. 4) My driver had issue in finup path which is not caught by kcapi test program :) regards Harsh Jain regards Harsh Jain On Tue, May 31, 2016 at 4:35 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Dienstag, 31. Mai 2016, 16:28:14 schrieb Harsh Jain: > > Hi Harsh, > >> Hi Stephen, >> >> Yes ,It's for Hash. The available API in library for hash update >> "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not >> trigger driver's digest/finup implementation. We need something like >> that >> >> _kcapi_common_accept() >> send(handle->opfd, buffer, len, 0); ==> flag = 0. >> >> It will execute digest callback of selected tfm from User >> Space.(init->digest) Similarly >> >> _kcapi_common_accept() >> send(handle->opfd, buffer, len, MSG_MORE); >> send(handle->opfd, buffer, len, 0); >> >> It will execute finup callback of selected tfm. (init->update->finup). >> >> In that way we can test all callbacks from userspace. In future if you >> feel this use case important. You can add API's to implement this. > > Ok, I see that the finup code path is not exercised in the kernel by my > library. > > Why do you think that this code path should be tested by my test code? > > The test code shall verify that libkcapi works fine. > > Ciao > Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 11:52 ` Harsh Jain @ 2016-05-31 11:55 ` Stephan Mueller 0 siblings, 0 replies; 13+ messages in thread From: Stephan Mueller @ 2016-05-31 11:55 UTC (permalink / raw) To: Harsh Jain; +Cc: linux-crypto Am Dienstag, 31. Mai 2016, 17:22:12 schrieb Harsh Jain: Hi Harsh, > Hi, > > 1) User can use libkcapi to write program for finup/digest. > 2) No, kernel test for finup (not sure). > 3) We can test all callback of new hash tfm drivers added in kernel. > 4) My driver had issue in finup path which is not caught by kcapi test > program :) Can you please elaborate on the last one? Maybe we should then extend the test app to really cover also all aspects of AF_ALG. Ciao Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-05-31 7:05 ` Stephan Mueller 2016-05-31 8:40 ` Harsh Jain @ 2016-12-19 10:38 ` Harsh Jain 2016-12-21 8:54 ` Herbert Xu 1 sibling, 1 reply; 13+ messages in thread From: Harsh Jain @ 2016-12-19 10:38 UTC (permalink / raw) To: Stephan Mueller, Herbert Xu; +Cc: linux-crypto Hi Herbert, TLS default mode of operation is MAC-then-Encrypt for Authenc algos. Currently framework only supports EtM used in IPSec. User space programs like openssl cannot use af-alg interface to encrypt/decrypt in TLS mode. Are we going to support Mac-then-Encrypt mode in future kernel releases? Regards Harsh Jain On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: > > Hi Harsh, > >> Hi All, >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from >> userspace program.I check libkcapi library. It has test programs for >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption, >> Which of them is supported in crypto framework. >> >> 1) Encrypt-then-MAC (EtM) >> The plaintext is first encrypted, then a MAC is produced based on >> the resulting ciphertext. The ciphertext and its MAC are sent >> together. >> 2) Encrypt-and-MAC (E&M) >> A MAC is produced based on the plaintext, and the plaintext is >> encrypted without the MAC. The plaintext's MAC and the ciphertext are >> sent together. >> >> 3) MAC-then-Encrypt (MtE) >> A MAC is produced based on the plaintext, then the plaintext and >> MAC are together encrypted to produce a ciphertext based on both. The >> ciphertext (containing an encrypted MAC) is sent. > > The cipher types you mention refer to the implementation of authenc(). IIRC, > authenc implements EtM as this is mandated by IPSEC. > > When you use libkcapi, you should simply be able to use your cipher name with > the AEAD API. I.e. use the examples you see for CCM or GCM and use those with > the chosen authenc() cipher. Do you experience any issues? > > Ciao > Stephan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-12-19 10:38 ` Harsh Jain @ 2016-12-21 8:54 ` Herbert Xu 2016-12-23 5:46 ` Harsh Jain 0 siblings, 1 reply; 13+ messages in thread From: Herbert Xu @ 2016-12-21 8:54 UTC (permalink / raw) To: Harsh Jain; +Cc: Stephan Mueller, linux-crypto On Mon, Dec 19, 2016 at 04:08:11PM +0530, Harsh Jain wrote: > Hi Herbert, > > TLS default mode of operation is MAC-then-Encrypt for Authenc algos. > Currently framework only supports EtM used in IPSec. User space > programs like openssl cannot use af-alg interface to encrypt/decrypt > in TLS mode. > Are we going to support Mac-then-Encrypt mode in future kernel releases? If someone finally adds TLS to the kernel then we'll likely do something about it. Otherwise you can just separate it out into two operations via af-alg. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Test AEAD/authenc algorithms from userspace 2016-12-21 8:54 ` Herbert Xu @ 2016-12-23 5:46 ` Harsh Jain 0 siblings, 0 replies; 13+ messages in thread From: Harsh Jain @ 2016-12-23 5:46 UTC (permalink / raw) To: Herbert Xu; +Cc: Stephan Mueller, linux-crypto On 21-12-2016 14:24, Herbert Xu wrote: > On Mon, Dec 19, 2016 at 04:08:11PM +0530, Harsh Jain wrote: >> Hi Herbert, >> >> TLS default mode of operation is MAC-then-Encrypt for Authenc algos. >> Currently framework only supports EtM used in IPSec. User space >> programs like openssl cannot use af-alg interface to encrypt/decrypt >> in TLS mode. >> Are we going to support Mac-then-Encrypt mode in future kernel releases? > If someone finally adds TLS to the kernel then we'll likely do > something about it. Till that time we cannot use crypto authenc type algos with AF-ALG socket interface for TLS or MtE( separation into 2 operation always not possible). TLS RFC7366 allow users to decide weather to use EtM or MtE in TLS. We can solve this, If we have some way to communicate drivers to operate in TLS mode like in setsockopt or msghdr of sendmsg. > Otherwise you can just separate it out into > two operations via af-alg. Always not possible. If openssl has software implementation of Authec( Cipher and hash with 1 algo) it expects same from af-alg engine only then he will override. Its like if Openssl has super set(AES+ SHA256) available it expect same super set in engine(af-alg) for comparison. The machines with instruction set extensions has authenc implemented in user space like intel aes-ni. > > Cheers, ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-12-23 5:46 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-31 7:01 Test AEAD/authenc algorithms from userspace Harsh Jain 2016-05-31 7:05 ` Stephan Mueller 2016-05-31 8:40 ` Harsh Jain 2016-05-31 8:59 ` Stephan Mueller 2016-05-31 9:15 ` Harsh Jain 2016-05-31 9:21 ` Stephan Mueller 2016-05-31 10:58 ` Harsh Jain 2016-05-31 11:05 ` Stephan Mueller 2016-05-31 11:52 ` Harsh Jain 2016-05-31 11:55 ` Stephan Mueller 2016-12-19 10:38 ` Harsh Jain 2016-12-21 8:54 ` Herbert Xu 2016-12-23 5:46 ` Harsh Jain
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.