[dm-crypt] dm-crypt overhead
numberfour at seznam.cz
Thu Mar 1 15:59:53 CET 2018
thanks for clarifications. Unfortunately, we are currently constrained to
use only dmsetup and cannot provision the target device with cryptsetup.
Thus we cannot use LUKS, only plain dm-crypt.
Hopefully it will change in the future. However, does this mean there is
currently no chance of using any form of authenticated encryption in our
2018-03-01 15:42 GMT+01:00 Milan Broz <gmazyland at gmail.com>:
> On 03/01/2018 03:24 PM, Lukáš Pohanka wrote:
> > I have a couple of questions regarding dm-crypt and overhead when using
> different encryption algorithms.
> > Firstly, am I right that the aes-xts-plain64 algorithm has no overhead,
> i.e. the size occupied at the target device is exactly the same as it would
> be without the dm-crypt layer?
> > Secondly, when using aes-gcm, is the authentication tag created
> per-sector? This means in this case there is an overhead per each sector
> (depending on the tag size)?
> > Also I couldn't find how the IV is calculated in case of aes-gcm, can
> also -plain64 be used?
> > Thanks in advance for clarifications.
> Hi Lukas,
> all default FDE modes are length-preserving, so there is no additional
> per-sector metadata space, so it cannot use AEAD.
> With LUKS2 I introduced authenticated encryption (still experimental)
> where you can use some authenticated modes,
> but there are many limitations for now.
> For the basic info see my FOSDEM slides
> and release notes for cryptsetup2
> Most of your questions should be answered there.
> (There is some paper submitted regarding this, I hope I can make it public
> soon, or mail me privately.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt