On Wed, Jan 05, 2022 at 09:55:17PM +0000, Bae, Chang Seok wrote: > >> +-----------+---------------+---------------+ > >> | Cipher | Encryption | Decryption | > >> | (AES-KL) | (MiB/s) | (MiB/s) | > >> +-----------+---------------+---------------+ > >> | AES-CBC | 505.3 | 2097.8 | > >> | AES-XTS | 1130 | 696.4 | > >> +-----------+-------------------------------+ > > > > Why is AES-XTS decryption so much slower than AES-XTS encryption? They should > > be about the same. > > Analyzing and understanding this with specific hardware implementation takes > time for us. Will come back and update you when we have anything to share here. Note that for disk encryption, decryption performance is usually more important than encryption performance. So your performance results are strange. > > Also, is the AES-CBC support really useful, given that for disk encryption, > > AES-XTS is recommended over AES-CBC these days? > > Yes, we understand that AES-XTS is the primary option for disk encryption. > > But it seems that AES-CBC had been used for disk encryption, [1]: > > Comparing XTS to CBC for hard disk encryption > If a storage device vendor is seeking FIPS 140-2 certification today, > they will typically use CBC encryption, or even ECB. CBC is a good > mode, ... That document is very old. XTS has been NIST-approved for over a decade now. > > As long as it is factual that the mode was once popular, it can help somebody > who wants to use Key Locker for an old disk image I think. AES-CBC is/was usually used with ESSIV, in which case the key cannot be fully protected by Key Locker. I'm not sure you should bother to support legacy use cases, especially since it might mislead users into choosing a worse algorithm. - Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel