On Mon, 17 Jun 2019 at 12:39, Milan Broz <gmazyland@xxxxxxxxx> wrote: > > On 17/06/2019 11:15, Ard Biesheuvel wrote: > >> I will also add that going the skcipher route rather than shash will > >> allow hardware tfm providers like CryptoCell that can do the ESSIV > >> part in hardware implement that as a single API call and/or hardware > >> invocation flow. > >> For those system that benefit from hardware providers this can be beneficial. > >> > > > > Ah yes, thanks for reminding me. There was some debate in the past > > about this, but I don't remember the details. > > > > I think implementing essiv() as a skcipher template is indeed going to > > be the best approach, I will look into that. > > For ESSIV (that is de-facto standard now), I think there is no problem > to move it to crypto API. > > The problem is with some other IV generators in dm-crypt. > > Some do a lot of more work than just IV (it is hackish, it can modify data, this applies > for loop AES "lmk" and compatible TrueCrypt "tcw" IV implementations). > > For these I would strongly say it should remain "hacked" inside dm-crypt only > (it is unusable for anything else than disk encryption and should not be visible outside). > > Moreover, it is purely legacy code - we provide it for users can access old systems only. > > If you end with rewriting all IVs as templates, I think it is not a good idea. > > If it is only about ESSIV, and patch for dm-crypt is simple, it is a reasonable approach. > > (The same applies for simple dmcryp IVs like "plain" "plain64", "plain64be and "benbi" that > are just linear IVs in various encoded variants.) > Agreed. I am mostly only interested in ensuring that the bare 'cipher' interface is no longer used outside of the crypto subsystem itself. Since ESSIV is the only one using that, ESSIV is the only one I intend to change.
