Hi Milan, I understand your suggestion and I gone through the document which you provided. I even dumped my IV value and got to know that it is fixed for each operation. I cannot use "random" as our requirement is not on that. So here I need to use encryption using aes-cbc-essiv only. I am using same key for dm-integrity and dm-crypt and I am saving the same key in keyring. So dm-crypt will take key from keyrings. After digging into the issue I found some patch regarding kernel dm- crypt driver. Can you please provide me the input on this, weather this patch will be helpful? https://lore.kernel.org/patchwork/patch/777700/ Regards, Sharmila On Wed, 2020-01-29 at 10:48 +0100, Milan Broz wrote: > Dear Sharmila, > > when I sent you to the list, because the issue tracker is not a > support forum > and our time is extremely limited, I expected you will AT LEAST read > the link > to the documentation I provided. > > Please do not expect from the community any support for questions you > just > copy&paste without even trying to study documentation yourself. > > Anyway. > > First, really think about using integritysetup/cryptsetup. Using > dmsetup > is super fragile (it is the lowest tool, basically just wrapper > through IOCTL). > > On 29/01/2020 09:18, EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF) wrote: > > Query: > > Whether Random number generator used to generate IV, > > generates > > same IV repeatedly or unique IV will be generated ? How the IV > > generation handled in dm-crypt ? > > https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt#iv-generators > > So, if you use "random" IV it is regenerated on every write (can be > used onlt for > authenticated encryption). > For other IVs it is either fixed (null) or derived from sector > offset. > > I would strongly suggest to use aes-xts-plain64 these days for length > preserving > encryption in dm-crypt. > > > The commands I used to create dm-integrity and dm-crypt is as below > > > > dmsetup create test-integrity --table '0 14240 integrity > > /dev/mmcblk0p5 > > 0 32 J 1 > > internal_hash:hmac(sha256):3031323334353637383941424344454630313233 > > 3435 > > 36373839414243444546' > > > > dmsetup create test-integrity-crypt --table '0 14240 crypt aes-cbc- > > essiv:sha256 :32:user:test-key 0 /dev/mapper/test-integrity 0' > > So here you use integrity protected device with keyded MAC, and over > it length preserving encryption using aes-cbc-essiv. > > So IV in dmcrypt is fixed, but unpredictable (derived from encryption > key). > > Again, read the documentation. > https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMIntegrity > > Namely that key specification for internal_hash is in hexa. > Your "random" HMAC key above is very suspicious in this regard, for > example. > > m. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
