How Useful is In-Guest Encryption?

[Hexagon]

@HulaHoop

Also libvirt introduced LUKS encryption for disk image volumes.

Is this the same as the encryption of qcow(2) images? There are some flaws in the implementation.

[HulaHoop]

@Patrick

There is cryptsetup-reencrypt. Meaning: we could ship encrypted images. The master key and the password (perhaps empty if possible) would be known to the public. Users could use cryptsetup-reencrypt to fix the master key and password, i.e. to make the encryption effective.
At least as far as I understand. This would solve a redistribution
issue (images downloadable by the public) that I mentioned earlier
somewhere.

Yes I get it. I think that would be awesome. The impact should be negligible thanks to AES acceleration.

@Hexagon

While it seems obvious it might be worth noting in the wiki that you can’t use sparse images if you want to initialize the disk with random data (which is recommended to prevent disclosure of usage patterns on the encrypted drive).

Hm. That poses a huge obstacle since images are potentially 100GB each. I think this advice is good for extra precautions against known ciphertext attacks but realistically I don’t believe this allows cracking AES completely?

[HulaHoop]

@Hexagon

Is this the same as the encryption of qcow(2) images? There are some flaws in the implementation.

No its the newer implementation using LUKS instead of the home-brew image format specific one they had earlier which was deprecated in the link you posted.

[Hexagon]

@HulaHoop

That poses a huge obstacle since images are potentially 100GB each. I think this advice is good for extra precautions against known ciphertext attacks but realistically I don’t believe this allows cracking AES completely?

AES is safe without random data for the free space it’s just to prevent some meta data leaks such as what parts of the disk are encrypted and how much is stored. You also wouldn’t want to distribute such images where the space is already filled because then everyone would have the same supposedly random data. (images would still be larger though because you can’t compress them anymore with xz)

[quote=“HulaHoop, post:23, topic:1253”]
No its the newer implementation using LUKS instead of the home-brew image format specific one they had earlier[/quote]

Ah, good to know. Thanks.