4 ms·
> especially the part that allows subvolumes and multiple password slots Admittedly backup headers are not yet implemented. (I had to release an MVP at some po
by notfed 6y ago
> especially the part that allows subvolumes and multiple password slots
Admittedly backup headers are not yet implemented. (I had to release an MVP at some point.)
> how [is] data integrity is handled?
(Beware though that this is still MVP, and the code doesn't actually write a backup header yet. If enough people are enthusiastic about PUREE, I promise to do so.)
Every part of the header is encrypted+authenticated. If any part of the header has a bit-flip, the message-authentication code will fail to decrypt the header. PUREE can't tell whether this happened or you're just providing the wrong password. If corruption does occur, you'd need to hint to PUREE to read a backup header---by default, one will be at the final 1MiB of the device. (But again I stress, not implemented yet.)
> How large are the blocks, does this affect other blocks, and how can intact blocks be recovered?
PUREE just handles the header. After that, it hands control to the next stage, which according to the spec, can really be anything. The implementation, as it is now, only has four possible encryption modes, and each just hands things off to Linux dm-crypt subsystem. You'd have to read about that in dm-crypt.
- WhatIsDukkha 6y agoThis touches on one of the great problems of encrypted disks. Anything on the volume is almost by definition important. But a single bit flip and it can be complete garbage. It would be lovely if someone, far more clever then me, layered fountain codes https://en.wikipedia.org/wiki/Fountain_code https://en.wikipedia.org/wiki/Fountain_code at a tasteful spot.
- dheera 6y ago> But a single bit flip and it can be complete garbage ECC?
- fwip 6y agoCan any class of "data with ECC" be made indistinguishable from random data, excepting obscurity?
- dfox 6y agoIt can: you can just apply encryption after the FEC/ECC. This is done for example in GSM and I believe in many other radio systems. Of course there is one huge caveat: it inherently means that you are doing MAC-then-Encrypt which is generally disliked as error-prone.
- fwip 6y agoRight, if you get a bitflip error in the encrypted data, decrypting it isn't going to yield something that the error-correcting-codes work on, right? It'll potentially ruin all your data, not just the single affected bit. I guess if GSM is doing it it must be useful, I need to read up on that.
- dfox 6y agoStream cipher preserves bit-flips between ciphertext and plaintext, which is useful property for this application. And many “military/diplomatic” ciphersystems used in second half of 20th century have various interesting properties wrt. error correction or non-propagation. My suspicion is that these properties are built by doing MAC-then-FEC-then-Encrypt and in some cases even by relying on limited error propagation of CBC mode. If you think about it, for these applications reliability is more interesting than strict authentication as the ciphertext of diplomatic “cable” or similar thing is sent through somewhat noisy channels and often was manually handled by fallible human radio operators while active MitM was not exactly feasible attack.
- fwip 6y agoThank you for all this explanation, I appreciate it. :)