linux-kernel - Re: [PATCH v5 3/8] crypto: AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Dec 2014 09:54:33 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Daniel Borkmann <dborkman@...hat.com>,
	'Quentin Gouchet' <quentin.gouchet@...il.com>,
	'LKML' <linux-kernel@...r.kernel.org>,
	linux-crypto@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

Am Mittwoch, 24. Dezember 2014, 07:24:01 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> > Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
> > > 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.
> 
> What I mean is that unlike skcipher we cannot precede until we
> have the complete input.  So you cannot begin recvmsg until all
> input has been sent.

That is right, but isn't that the nature of AEAD ciphers in general? Even if 
you are in the kernel, you need to have all scatter lists together for one 
invocation of the AEAD cipher.

In case of a threaded application, the recvmsg does not start until all data 
is in, marked with the missing MSG_MORE -- see aead_readable.

All we can do is allow the user to use multiple system calls to collect all 
data before the AEAD operation takes place.

Or do you see another way on how to invoke the AEAD operation in a different 
manner?

The only item that I see that could be made better is the output side: 
currently the code allows only one and exactly one iovec to point to the 
output buffer. I would like to allow multiple iovec buffers that are filled 
with the output of one invocation of the AEAD operation. However, to avoid 
making a kernel-internal scratch buffer, I would need to somehow link the 
kernel-internal scatter lists with the iovec buffers. That only works when 
walking the iovec lists first and call af_alg_make_sg with every iovec entry 
and create the kernel-internal scatterlist representation. That is followed by 
the AEAD operation on the scatterlist.

If we agree on walking the iovec list first, then the question arises how many 
iovec list entries we allow at max. Is 16 entries a sensible value?

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/