Generally speaking hard drive encryption protects against theft and not tampering. I.e. the idea is that if your laptop or NAS is "lost and found", then you wipe the drive and restore from backup, not continue to use the drive.<p>-<p>Since the protocol used here is broken the fix is to change the protocol - so keep in mind that...<p>> The former reencryption operation (without the additional digest) is no
longer supported (reencryption with the digest is not backward
compatible). <i>You need to finish in-progress reencryption before
updating to new packages.</i> The alternative approach is to perform
a repair command from the updated package to recalculate reencryption
digest and fix metadata.<p>Just in case you were thinking about upgrading the software during re-encryption - don't.
What's still unclear to me: can you just grab an encrypted device (cold) and decrypt it? Or does the attack require a "live" device i.e one where the passphrase already have been given and the device is online?
> LUKS2 online reencryption is an optional extension to allow a user to
change the data reencryption key while the data device is available for
use during the whole reencryption process.<p>Since it's optional, is it possible to see if this is enabled or disabled, and how to disable it?
Some people keep the LUKS2 volume header in a separate file that's encrypted (e.g., with gpg). Would someone still be able to attack a cold volume using this vulnerability in that case?
> The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step.<p>First time I'm glad grub cannot boot LUKS2.
Could then NSA crack any LUKS encrypted container held on cloud storage such as Dropbox or GDrive (opened with a key on client side, never entered on server)?