On Fri, Jan 13, 2017 at 01:01:56PM +0100, Ondrej Mosnáček wrote: > > As I already mentioned in another thread, there are basically two reasons: > > 1) Milan would like to add authenticated encryption support to > dm-crypt (see [1]) and as part of this change, a new random IV mode > would be introduced. This mode generates a random IV for each sector > write, includes it in the authenticated data and stores it in the > sector's metadata (in a separate part of the disk). In this case > dm-crypt will need to have control over the IV generation (or at least > be able to somehow retrieve it after the crypto operation... but > passing RNG responsibility to drivers doesn't seem to be a good idea > anyway).
This sounds exactly like the IV generator for IPsec modes such as CTR or GCM. The only difference is that you deal with sectors instead of packets. > 2) With this API, drivers wouldn't have to provide implementations for > specific IV generation modes, and just implement bulk requests for the > common modes/algorithms (XTS, CBC, ...) while still getting > performance benefit. What if the driver had hardware support for generating these IVs? With your scheme this cannot be supported at all. Getting the IVs back is not actually that hard. We could simply change the algorithm definition for the IV generator so that the IVs are embedded in the plaintext and ciphertext. For example, you could declare it so that the for n sectors the first n*ivsize bytes would be the IV, and the actual plaintext or ciphertext would follow. With such a definition you could either generate the IVs in dm-crypt or have them generated in the IV generator. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
