All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
To: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Cc: Daniel Borkmann
	<dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	'Quentin Gouchet'
	<quentin.gouchet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	'LKML' <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support
Date: Tue, 23 Dec 2014 15:52:27 +0100	[thread overview]
Message-ID: <4537021.IXSvIIgcH4@tachyon.chronox.de> (raw)
In-Reply-To: <20141223115626.GA31450-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>

Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
> > - the check aead_readable() immediately before this check implements the
> > blocking if we do not have sufficient data *and* more data is to be
> > expected
> Good point.
> 
> In fact AEAD is rather awkward because you need to do everything
> in one go.  Perhaps we could adapt our kernel interface to allow
> partial AEAD operations?


I am not sure what you are referring to. The invocation does not need to be in 
one go. You can have arbitrary number of sendmsg calls. But all input data 
needs to be supplied before you call recvmsg.

Please see my test code that implements the following call sequence using the 
libkcapi wrapper API calls where I dissect the data to be sent to the kernel 
for testing purposes:

if (cavs_test->enc) {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_enc(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with last call */
                iov.iov_base = cavs_test->pt;
                iov.iov_len = cavs_test->ptlen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        } else {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_dec(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with intermediary call */
                iov.iov_base = cavs_test->ct;
                iov.iov_len = cavs_test->ctlen;
                ret = kcapi_aead_stream_update(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending update buffer failed\n");
                        goto out;
                }
                /* send tag with last send call */
                iov.iov_base = cavs_test->tag;
                iov.iov_len = cavs_test->taglen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        }

Every call to kcapi_aead_stream_init_dec / kcapi_aead_stream_update / 
kcapi_aead_stream_update_last invokes one sendmsg syscall.

In essence, kcapi_aead_stream_update can be invoked with every byte you want 
to add to the message stream. This "stream" API of libkcapi is logially 
equivalent to the init/update/final of message digests.
> 
> I want to be very careful before we pin down our user-space
> interface since that's something that we cannot easily change
> while the kernel interface can be modified at any time.

I am fully with you and try to patiently present solutions.
> 
> Thanks,


-- 
Ciao
Stephan

WARNING: multiple messages have this Message-ID (diff)
From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Daniel Borkmann <dborkman@redhat.com>,
	"'Quentin Gouchet'" <quentin.gouchet@gmail.com>,
	"'LKML'" <linux-kernel@vger.kernel.org>,
	linux-crypto@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support
Date: Tue, 23 Dec 2014 15:52:27 +0100	[thread overview]
Message-ID: <4537021.IXSvIIgcH4@tachyon.chronox.de> (raw)
In-Reply-To: <20141223115626.GA31450@gondor.apana.org.au>

Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
> > - the check aead_readable() immediately before this check implements the
> > blocking if we do not have sufficient data *and* more data is to be
> > expected
> Good point.
> 
> In fact AEAD is rather awkward because you need to do everything
> in one go.  Perhaps we could adapt our kernel interface to allow
> partial AEAD operations?


I am not sure what you are referring to. The invocation does not need to be in 
one go. You can have arbitrary number of sendmsg calls. But all input data 
needs to be supplied before you call recvmsg.

Please see my test code that implements the following call sequence using the 
libkcapi wrapper API calls where I dissect the data to be sent to the kernel 
for testing purposes:

if (cavs_test->enc) {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_enc(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with last call */
                iov.iov_base = cavs_test->pt;
                iov.iov_len = cavs_test->ptlen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        } else {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_dec(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with intermediary call */
                iov.iov_base = cavs_test->ct;
                iov.iov_len = cavs_test->ctlen;
                ret = kcapi_aead_stream_update(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending update buffer failed\n");
                        goto out;
                }
                /* send tag with last send call */
                iov.iov_base = cavs_test->tag;
                iov.iov_len = cavs_test->taglen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        }

Every call to kcapi_aead_stream_init_dec / kcapi_aead_stream_update / 
kcapi_aead_stream_update_last invokes one sendmsg syscall.

In essence, kcapi_aead_stream_update can be invoked with every byte you want 
to add to the message stream. This "stream" API of libkcapi is logially 
equivalent to the init/update/final of message digests.
> 
> I want to be very careful before we pin down our user-space
> interface since that's something that we cannot easily change
> while the kernel interface can be modified at any time.

I am fully with you and try to patiently present solutions.
> 
> Thanks,


-- 
Ciao
Stephan

  parent reply	other threads:[~2014-12-23 14:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-07 22:20 [PATCH v5 0/8] crypto: AF_ALG: add AEAD and RNG support Stephan Mueller
2014-12-07 22:20 ` Stephan Mueller
2014-12-07 22:21 ` [PATCH v5 1/8] crypto: AF_ALG: add user space interface for AEAD Stephan Mueller
2014-12-08  6:50   ` Stephan Mueller
2014-12-07 22:21 ` [PATCH v5 2/8] crypto: AF_ALG: add setsockopt for auth tag size Stephan Mueller
2014-12-22 12:05   ` Herbert Xu
2014-12-07 22:22 ` [PATCH v5 3/8] crypto: AF_ALG: add AEAD support Stephan Mueller
2014-12-22 11:23   ` Herbert Xu
2014-12-23  8:14     ` Stephan Mueller
     [not found]       ` <101382546.xjTjAHLGAb-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-12-23 11:56         ` Herbert Xu
2014-12-23 11:56           ` Herbert Xu
     [not found]           ` <20141223115626.GA31450-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-12-23 14:52             ` Stephan Mueller [this message]
2014-12-23 14:52               ` Stephan Mueller
     [not found]               ` <4537021.IXSvIIgcH4-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-12-23 20:24                 ` Herbert Xu
2014-12-23 20:24                   ` Herbert Xu
     [not found]                   ` <20141223202401.GA2474-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-12-24  8:54                     ` Stephan Mueller
2014-12-24  8:54                       ` Stephan Mueller
     [not found]                       ` <2159528.zCJB0y2Cap-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-12-25  8:59                         ` Stephan Mueller
2014-12-25  8:59                           ` Stephan Mueller
2014-12-25 20:28                         ` Herbert Xu
2014-12-25 20:28                           ` Herbert Xu
2014-12-07 22:23 ` [PATCH v5 4/8] crypto: AF_ALG: enable AEAD interface compilation Stephan Mueller
2014-12-07 22:23 ` [PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG Stephan Mueller
     [not found]   ` <3380968.kTQNpvjKFa-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-12-22 11:27     ` Herbert Xu
2014-12-22 11:27       ` Herbert Xu
     [not found]       ` <20141222112730.GB19532-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-12-23  8:27         ` Stephan Mueller
2014-12-23  8:27           ` Stephan Mueller
2014-12-07 22:25 ` [PATCH v5 7/8] crypto: AF_ALG: add random number generator support Stephan Mueller
     [not found] ` <56740432.V2v4gLHrzS-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-12-07 22:24   ` [PATCH v5 6/8] crypto: AF_ALG: zeroize key / seed data Stephan Mueller
2014-12-07 22:24     ` Stephan Mueller
2014-12-07 22:25   ` [PATCH v5 8/8] crypto: AF_ALG: enable RNG interface compilation Stephan Mueller
2014-12-07 22:25     ` Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4537021.IXSvIIgcH4@tachyon.chronox.de \
    --to=smueller-t9tcv8ipfcwelga04laivw@public.gmane.org \
    --cc=dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=quentin.gouchet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.