> I understand that LUKS' concern is to protect data from unauthorized > access, but couldn't a compromise be found? The randomly-placed backup > header idea proposed by Jonas seems nice. Implementation-wise, if the > position of the backup header is known, then LUKS can just make a > second shift when accessing sectors after that position. Wouldn't this > be an acceptable solution? No. The answer is, use plan cryptsetup, and don't use LUKS unless you know what you are doing (same goes for plain cryptsetup, but there the worst that can happen is a leaked key and complete reencryption becoming necessary, or a forgotten key, and all data gone). Sadly LUKS is being peddled as "more comfortable, more awesome, the future", which it is, in some scenarios, but it introduces additional weaknesses (cryptographic and data safety), that have to be managed very thoughtfully. The real prolbem, that I see, is that cryptsetup -luksblah doesn't quite warn/block enough, and why anyone would use --batch-mode anywhere but in mass deployments of new clients, is beyond comprehension. Something that might be doable is creating a backup-LUKS header on a separate device, which is itself setup to contain a single key to unlock the main key, which isn't used in the production LUKS. That way revocation of keys isn't a problem. You will likely just forget the back-up passphrase. Still, that should provide a cryptographically strong means of keeping a LUKS-header around that will unlock your data in case of a major problem. Best to put it onto an USB-key or something and lock it in a safe. Still, plain dm-crypt is a much simpler solution to avoid single-line-erasing terabytes of data in the blink of an eye. Also, I'd like to hear from the devs/maintainers, if there's any reason why my proposed approach to a LUKS back-up might be flawed. If not, that might be something to implement in a future version, on luks-create (asking for a second device, and a second passphrase). Have a nice week-end, all. Rick _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
