On Thu, May 18, 2017 at 01:40:38PM +0200, Ondrej Mosnacek wrote: > > > Actually I think this one can probably easily handled in the crypto > > layer. All we need is to add a multikey template that sits on top > > of an underlying IV generator. The multikey instance can then accept > > a key length that is a multiple of the underlying key length. > > I thought of that, too, but unfortunately with TCW the key structure is: > > | KEY 1 | KEY 2 | ... | KEY n | IV SEED (size = IV size) | WHITENING > (size = 16 bytes) | > > So part of the key needs to be processed before it is split into multiple keys. > > Also with the LMK mode, there is a similar optional key appendix, > which is of the same size as the other subkeys. The format of the key isn't an issue. Because we're writing this from scratch. We can change the format in any way we want, e.g., we could include the value n if we wanted in the key stream. Yes dm-crypt would need to massage the key before passing it over to the crypto layer, but that should be pretty easy. > My point is that it doesn't make much sense to have a crypto API alg > that calls get_random_bytes() as part of its implementation. IMHO, > that might tempt HW drivers to replace it with some crappy > alternatives, which wouldn't be good... Also, how would we test such > alg with testmgr? You are right. There is no way we can judge the quality of a hardware IV generator, just as there is no way to judge the quality of hardware RNG without looking at its internal structure. But that doesn't mean that we shouldn't support them if they exist. In any case, this scenario already exists today with IPsec where we have multiple hardware implementations that generate the IV. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
