Hi Milan, On Thu, Sep 13, 2018 at 8:40 AM Milan Broz <gmazyland@xxxxxxxxx> wrote: > Please note, that dm-crypt now uses not only block ciphers and modes, > but also authenticated encryption and hashes (for ESSIV and HMAC > in authenticated composed modes) and RNG (for random IV). > We use crypto API, including async variants (I hope correctly :) > > There is a long time battle to move initialization vectors generators > from dm-crypt to crypto API. If there are any plans to use a new library, > this issue should be discussed as well. > (Some dm-crypt IV generators are disk encryption specific, some do more > that just IV so porting is not straightforward etc). > > Related problem here is an optimization of chain of sectors encryption - > if we have new crypto API, it would be nice if can take chain of sectors > so possible implementation can process this chain in one batch > (every sector need to be tweaked by differently generated IV - and we > are back in problem above). > I think filesystem encryption uses the same pattern. > > And btw, we use the same algorithms through AF_ALG in userspace (cryptsetup). > > So please, if you mention dm-crypt, note that it is very complex > crypto API consumer :) And everything is dynamic, configurable through > dm-crypt options. > > That said, I would be more than happy to help in experiments to porting dm-crypt > to any other crypto library, but if it doesn't not help with problems > mentioned above, I do not see any compelling reason for the new library for dm-crypt... dm-crypt is probably a good consumer of the existing crypto API and won't be impacted by the introduction of Zinc, which is really just the exposure of a couple low level simple crypto functions, and not a fancy API like the crypto API which dm-crypt happily uses. Jason
