On Fri, 2022-01-14 at 12:18 +0100, Ondrej Kozina wrote: > > 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? > > Not without user manual intervention. Currently, the reencryption > operation can not be resumed unless user directly issue "cryptsetup > reencrypt" command (applies to both fixed and vulnerable > cryptsetups). Then I don't understand the attack... cause if t would be only resumed if one enters a command manually, the attacked user would notice? > On the other hand, the vulnerability primarily targets LUKS2 > reencryption auto-recovery feature. Auto-recovery takes place in two > scenarios: ... > b) LUKS2 device activation e.g. during system boot. Okay that's the situation I've had meant before. > So the recovery from > reencryption crash is seamless provided user knows passphrase. And that's the point where I'd have expected the full decryption, i.e.: - an attacker messes with the headers while the device is offline - the user opens it (e.g. on next boot), doesn't notice anything - cryptsetup "continues" silently, but actually decrypts > In corner case, when device is small enough to fit limits disclosed > in > the vulnerability report (and LUKS2 spare metadata space allows it) > the > auto-recovery may actually finish the decryption process (in one > step). I think I don't understand how the spare header space affects this? I thought you'd just use that as kind of a journal? And to keep a copy of the region that is currently re-encrypted, and once that one has finished it would move on? > > or because an attack started only e.g. at > > half o the blocks, but then one half is encrypted and the other > > not? > > Nope, in this case device would activate just fine, part of the > device > encrypted and part plaintext (multi segment device-mapper device). > Otherwise we would be unable to activate partially decrypted devices > due > to interruption. Same applies to devices in encryption or > reencryption. So you keep book (in a secured way?) on which regions have been re- encrypted already and which not? I assumed it would be just some "pointer" that shows at one position from start to end, where the system currently was. > Ransomware attack is not possible provided attacker does not know > valid > passphrase or VK, if that's what you're asking: That was less about ransomware attack... cause when an attacker would have access to the offline device, he'd either compromised the system already, or has physical access... and in both cases he could also just do the attack (or simply steal the physical device). I was rather just wondering, whether during encrypting the new key is ever written to disk in an insecure way (which they keyslot, where it is encrypted, wouldn't be) > That would not be possible with LUKS2 format, or better say with > current > version of API of libcryptsetup. If the whole header was to be > protected > by MAC it would require complete rework of API which would not be > backward compatible. It would probably be LUKS3 format/library. Well... could save us from troubles some day ;-) > Also, just for LUKS2 reencryption, it would completely kill the > performance of the operation. During LUKS2 reencryption the json > metadata area gets updated quite often (twice per single reencryption > step which is typically ~100MiBs of data reencrypteed with checksum > resilience mode). If we calculated authentication digest (time > expensive > operation) in each step twice it would not go fast. That refers to the information on which regions have already been re- encrypted right? I assume, unless re-"encryption" to plain text is performed,... the clear-text never goes on disk during a "normal" re-encryption?! Thanks, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
