Hi Milan,
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 case?
Thanks,
Lukas
2018-03-01 15:42 GMT+01:00 Milan Broz <gmazyland@xxxxxxxxx>:
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
https://fosdem.org/2018/schedule/event/cryptsetup/
and release notes for cryptsetup2
https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/ v2.0.0-ReleaseNotes
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.)
Milan
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
