cc: Viro because I'm talking about iov_iter. On Sat, Dec 10, 2016 at 6:45 AM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > Hi Herbert, > > On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: >> As for AEAD we never had a sync interface to begin with and I >> don't think I'm going to add one. > > That's too bad to hear. I hope you'll reconsider. Modern cryptographic > design is heading more and more in the direction of using AEADs for > interesting things, and having a sync interface would be a lot easier > for implementing these protocols. In the same way many protocols need > a hash of some data, now protocols often want some particular data > encrypted with an AEAD using a particular key and nonce and AD. One > protocol that comes to mind is Noise [1]. > I think that sync vs async has gotten conflated with vectored-vs-nonvectored and the results are unfortunate. There are a lot of users in the tree that are trying to do crypto on very small pieces of data and want to have that data consist of the concatenation of two small buffers and/or want to use primitives that don't have "sync" interfaces. These users are stuck using async interfaces even though using async implementations makes no sense for them. I'd love to see the API restructured a bit to decouple all of these considerations. One approach might be to teach iov_iter about scatterlists. Then, for each primitive, there could be two entry points: 1. A simplified and lower-overhead entry. You pass it an iov_iter (and, depending on what the operation is, an output iov_iter), it does the crypto synchronously, and returns. Operating in-place might be permitted for some primitives. 2. A full-featured async entry. You pass it iov_iters and it requires that the iov_iters be backed by scatterlists in order to operate asynchronously. I see no reason that the decisions to use virtual vs physical addressing or to do vectored vs non-vectored IO should be tied up with asynchronicity. --Andy -- 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
