On Mon, 17 Jun 2019 at 12:58, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > 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. OK, so inferring the block cipher name from the skcipher algo name is a bit finicky, since the dm-crypt code does that *after* allocating the TFMs, and allocating the essiv skcipher happens before. But more importantly, it appears to be allowed currently to use ESSIV with authenticated modes, which means we'd need both a skcipher and a aead essiv template, or do some non-trivial hacking to insert the essiv template in the right place (which I'm not sure is even possible) So my main question/showstopper at the moment is: which modes do we need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers and AEADs? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
