Am Mittwoch, 24. Dezember 2014, 09:54:33 schrieb Stephan Mueller: Hi Stephan, > 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? I would be now ready with a new release of the AEAD and RNG interface patches against the current code base (including the iov_iter update). Though, I would like to get your answer regarding your concerns. Thanks. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
