>On Sat, Jan 07, 2023 at 02:33:31PM +0000, Nathan Carruth wrote: >>The way I see it, this depends on one's use case. >>There certainly are cases where it is important to be able >>to irrevocably destroy all data in an instant. But there are >>also use cases where one is only interested in making sure >>that the average person couldn’t access one’s data if one lost >>one’s laptop/external drive. >> >>I still think that anyone with the second use case could benefit >>from more documentation as I suggested, but I get the feeling >>this opinion is in the distinct minority here. > >If you're part of that supposed minority: count me in. If it's true >that the headers of encrypted disks on Openbsd are set up in a similar >way as on e.g. Linux, then it's actually a good idea to be able to >have precise knowledge about how to backup that header on OBSD.
> From what I learned the preparation for that failure includes first a >copy of the data on that encrypted disk to a second or - even better - >a third encrypted one. > >But copying back a whole disk because on the original broken one it's >just the header that went south might be an effort that is a least >avoidable. And this when part two of disaster preparation might be >helpful: the so-called header backup. > >I don't know how often, and if, such header corruptions on encrypted >disks happen on OBSD, but on LUKS/cryptsetup encrypted disks on >Linux this does not seem to be that unusual - from the LUKS FAQ: > >"By far the most questions on the cryptsetup mailing list are from > people that managed to damage the start of their LUKS partitions, > i.e. the LUKS header. In most cases, there is nothing that can be done > to help these poor souls recover their data. Make sure you understand > the problem and limitations imposed by the LUKS security model BEFORE > you face such a disaster! In particular, make sure you have a current > header backup before doing any potentially dangerous operations." > >https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md > >And so, that no one is getting me wrong: I don't expect anyone to >create the documentation for me. Definitively not. But if disk header >corruption can be a problem on Openbsd, too, then this very >possibility helps at least to understand the point the OP was trying >to make when starting this thread. > >Regards, >Wolfgang I wasn't going to say anything more, but after reading this I figured I ought to at least suggest an update to the documentation. Since I'm definitely not qualified to document the details, all I can really do is something like what is posted below (these should be diffs to the current versions of src/share/man/man4/softraid.4 and www/faq/faq14.html on CVS). Thanks, Nathan For softraid.4: @@ -270,0 +271,4 @@ +.Pp +The CRYPTO discipline emphasizes confidentiality over integrity. +In particular, corruption of the on-disk metadata will render all encrypted +data permanently inaccessible. For faq14.html: @@ -835,0 +836,9 @@ +<h4 id="softraidFDEheader">Note</h4> + +Decryption requires the use of on-disk metadata documented in the +<a href="https://cvsweb.openbsd.org/src/sys/dev/softraidvar.h";>source</a>. +Corruption of this metadata can easily render all encrypted data +permanently inaccessible. +There is at present no automated way to backup this metadata. +
