Atemu

Gotta love them tree NFTs.

Ich bin der OP des Kommentars, an den du eine Frage gestellt hast. Ich verstehe nicht ganz, worüber du dich wunderst?

Und meist ist das Backup auf dem NAS.

Wenn die einzige Kopie der Daten auf dem NAS liegen, hat man keine Backups.

Zweites NAS für das Backup oder nochmal eine Festplatte am NAS?

Ich habe ein paar externe Festplatten für physisch nahe und frequente backups und eine Sammlung an e-waste Platten (120G - 2T), die ich off-site für Cold Storage verwende.

Dazu sind manche Arten von Daten (wie etwa Dokumente) auf allen meinen Desktop Maschinen Repliziert. Ich glaube für Dokumente im speziellen werd ich noch Cloud Storage ins Spiel nehmen.

I also get my bank statements digitally; those are trivial to handle.

This is about scans of physical paper.

I am not sure which second paragraph you're referencing as your original comment only contains one.

I care that the text remains readable (both to me and also software) and that I don't balloon my storage out of control.

JPEG (even at higher levels) subjectively degrades text in particular to a degree that I worry about the former and PNG makes me worry about the latter.

My current plan is to go with the latter since storage is a relatively cheap issue to fix while data loss is pretty much permanent.

Note that this is of course a very theoretical attack vector.

Wouldn’t it then decrypt to gibberish data unless they already had the encryption keys?

Depends. I don't know the situation of LUKS and its commonly used ciphers in particulare but even some commonly used ciphers are vulnerable to things like bitflip attacks.

This is usually "fixed" by authenticating them but that's not easily possible at the block layer.

If it decrypts incorrectly, shouldn’t BTRFS checksumming then return an I/O error to user space as well?

Note that btrfs usually uses CRCs, not cryptographic checksums. They're designed to catch "naturally" occuring corruption, not crafted corruption. Naturally, it'd still be extremely hard to break them when working with encrypted data but it's a "uh, sounds pretty hard" situtation, not a "we can prove you'd need billions of years to do it" one.

You can use cryptographic checksums but note again here that the attacker could be able to modify the checksum aswell.

I don't know how feasible this really is a but a possible attack could be to tell btrfs that the extent you modified is a nochecksum extent (you can turn off checksums in btrfs) which would make btrfs simply not check the checksum.

Actual authentication fixes all of that.

Aus einem Backup wiederherstellen? Was denn sonst?

Außerdem, moderne Platten gehen ziemlich selten kaputt. Die Chancen stehen gut, dass meine das nächste Jahrzehnt überlebt.

1x Toshiba 18TB Enterprise; war ca. 300EUR und pro TB sehr Preiswert.

Ich brauch kein RAID und 18TB reichen mir noch. Ich werd bald aber wahrscheinlich um eine 16TB+ Platte erweitern, je nach dem was am günstigsten/TB ist.

Hab auch ein Eigenbau NAS ;) Bei mir mit J4105.

PDF/A is not an image format. As a document, it may contain images.

Possibilities at the block layer are generally quite limited since it only has limited means to work with. It's very low-level. For example, it is not possible to do authentication in LUKS. An attacker can't read the data but they can modify it; undetected.
You need to stack another layer on top and I'm not sure that's even a thing.

The patch mentions that authenticated hashes aren't supported yet either but with effectively limitless metadata to work with, it's at least possible to do.

Per-directory/subvolume encryption is also a useful feature. You could encrypt the root fs which generally does not contain sensitive information using a key in TPM but then require a password to unlock the user's home. That's basically how it works in Android and it builds on top of fscrypt.

I homebrew the ROM on my personal phone and I can tell you from first hand experience that you need the vendor dirs extracted from the OEM ROM. You can read up on that on the wiki pages for building any device ROM.

You can also come to that conclusion the other way around: How else would you (or LOS maintainers) get your hands on proprietary blobs full of secret sauce that vendors sometimes even try to actively block access to?

That's nice and all but does not answer how you'd create the PDF. Whether that happens outside paperless inside paperless does not make a difference. In the end, I need to create a PDF/A out of some images and the question on how to encode these images still remains.