On Tue, Jan 17, 2017 at 12:20:02PM +0100, Ondrej Mosnáček wrote: > 2017-01-13 15:29 GMT+01:00 Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>: > > What if the driver had hardware support for generating these IVs? > > With your scheme this cannot be supported at all. > > That's true... I'm starting to think that this isn't really a good > idea. I was mainly trying to keep the door open for the random IV > support and also to keep the multi-key stuff (which was really only > intended for loop-AES partition support) out of the crypto API, but > both of these can be probably solved in a better way... As you said that the multi-key stuff is legacy-only I too would like to see a way to keep that complexity out of the common path. > > With such a definition you could either generate the IVs in dm-crypt > > or have them generated in the IV generator. > > That seems kind of hacky to me... but if that's what you prefer, then so be it. I'm open to other proposals. The basic requirement is to be able to process multiple blocks as one entity at the driver level, potentially generating the IVs there too. It's essentially the equivalent to full IPsec offload. Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
