2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef <gi...@benyossef.com>: > It really is an observation about overhead of context switches between > dm-crypt and > whatever/wherever you handle crypto - be it an off CPU hardware engine > or a bunch > of parallel kernel threads running on other cores. You really want to > burst as much as > possible.
[...] >> For XTS you need just simple linear IV. No problem with that, implementation >> in crypto API and hw is trivial. >> >> But for compatible IV (that provides compatibility with loopAES and very old >> TrueCrypt), >> these should be never ever implemented again anywhere. > >> >> Specifically "tcw" is broken, insecure and provided here just to help people >> to migrate >> from old Truecrypt containers. Even Truecrypt followers removed it from the >> codebase. >> (It is basically combination of IV and slight modification of CBC mode. All >> recent version switched to XTS and plain IV.) >> >> So building abstraction over something known to be broken and that is now >> intentionally >> isolated inside dmcrypt is, in my opinion, really not a good idea. >> > > I don't think anyone is interested in these modes. How do you support > XTS and essiv in > a generic way without supporting this broken modes is not something > I'm clear on though. Wouldn't adopting a bulk request API (something like what I tried to do here [1]) that allows users to supply multiple messages, each with their own IV, fulfill this purpose? That way, we wouldn't need to introduce any new modes into Crypto API and the drivers/accelerators would only need to provide bulk implementations of common modes (xts(aes), cbc(aes), ...) to provide better performance for dm-crypt (and possibly other users, too). I'm not sure how exactly these crypto accelerators work, but wouldn't it help if the drivers simply get more messages (in our case sectors) in a single call? I wonder, would (efficiently) supporting such a scheme require changes in the HW itself or could it be achieved just by modifying driver code (let's say specifically for your CryptoCell accelerator)? Thanks, Ondrej [1] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23007.html > > Thanks, > Gilad > > > > -- > Gilad Ben-Yossef > Chief Coffee Drinker > > "If you take a class in large-scale robotics, can you end up in a > situation where the homework eats your dog?" > -- Jean-Baptiste Queru
