Test AEAD/authenc algorithms from userspace

Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Stephan Mueller]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Stephan Mueller]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Stephan Mueller]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Stephan Mueller]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Stephan Mueller]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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

Re: Test AEAD/authenc algorithms from userspace

[Herbert Xu]

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

Re: Test AEAD/authenc algorithms from userspace

[Harsh Jain]

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,