On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote: > > By the move everything to cryptoAPI we are basically introducing some strange mix > of IV and modes there, I wonder how this is going to be maintained. > Anyway, Herbert should say if it is ok... Well there is precedent in how do the IPsec IV generation. In that case the IV generators too are completely specific to that application, i.e., IPsec. However, the way structured it allowed us to have one single entry path from the IPsec stack into the crypto layer regardless of whether you are using AEAD or traditional encryption/hashing algorithms. For IPsec we make the IV generators behave like normal AEAD algorithms, except that they take the sequence number as the IV. The goal here are obviously different. However, by employing the same method as we do in IPsec, it appears to me that you can effectively process multiple blocks at once instead of having to supply one block at a time due to the IV generation issue. > I really do not think the disk encryption key management should be moved > outside of dm-crypt. We cannot then change key structure later easily. It doesn't have to live outside of dm-crypt. You can register these IV generators from there if you really want. Cheers, -- 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
