On Mon, 12 Aug 2019 at 10:44, Milan Broz <gmazyland@xxxxxxxxx> wrote: > > On 12/08/2019 08:54, Ard Biesheuvel wrote: > > On Mon, 12 Aug 2019 at 09:33, Milan Broz <gmazyland@xxxxxxxxx> wrote: > >> Try for example > >> # cryptsetup luksFormat /dev/sdc -c aes-cbc-essiv:sha256 --integrity hmac-sha256 -q -i1 > >> > >> It should produce Crypto API string > >> authenc(hmac(sha256),essiv(cbc(aes),sha256)) > >> while it produces > >> essiv(authenc(hmac(sha256),cbc(aes)),sha256) > >> (and fails). > >> > > > > No. I don't know why it fails, but the latter is actually the correct > > string. The essiv template is instantiated either as a skcipher or as > > an aead, and it encapsulates the entire transformation. (This is > > necessary considering that the IV is passed via the AAD and so the > > ESSIV handling needs to touch that as well) > > Hm. Constructing these strings seems to be more confusing than dmcrypt mode combinations :-) > > But you are right, I actually tried the former string (authenc(hmac(sha256),essiv(cbc(aes),sha256))) > and it worked, but I guess the authenticated IV (AAD) was actually the input to IV (plain sector number) > not the output of ESSIV? Do I understand it correctly now? > Indeed. The former string instantiates the skcipher version of the ESSIV template, and so the AAD handling is omitted, and we end up using the plain IV in the authentication rather than the encrypted IV. So when using the latter string, does it produce any error messages when it fails? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
