Hey. On Thu, 2022-01-13 at 11:05 +0100, Milan Broz wrote: > An attacker can modify on-disk metadata to simulate decryption in > progress with crashed (unfinished) reencryption step and > persistently > decrypt part of the LUKS device. Just for my understanding... 1) Wouldn't that then cause complete decryption? I.e. cryptsetup sees that re-encrypt (to plain text) was allegedly aborted at block XYZ... and then re-encrypts (to plain text) from there on the whole device? 2) And shouldn't that fail then next time, the device is opened? Either because it was completely transformed to plain text, while some encryption is expected... or because an attack started only e.g. at half o the blocks, but then one half is encrypted and the other not? 3) Would it also have been possible, to re-encrypt with another key? In other words, is the new key written to some extra header area... or is it rather just some new keyslot, encrypted with a passphrase, and thus that would have been (hopefully) noticed when "resuming" re-encryption, and the passphrase doesn't match (respectively the legit user cannot unlock the keylslot)? > The attack is not applicable to LUKS1 format, but the attacker can > update metadata in place to LUKS2 format as an additional step. Shouln't "all" (at least as far as possible) of the header be secured by some MAC or so, so that cryptsetup would abort before opening, when something seems fishy? Not just with respect to re-encryption, but also e.g. which header version is used, or settings like whether DISCARD shall be used (which may have some security impact)? Thanks, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
