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... > 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. That seems kind of hacky to me... but if that's what you prefer, then so be it. Cheers, Ondrej > > 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
