IV generation for dm-crypt

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.