On 2019-04-08 09:30, Leonid Bloch wrote:
On 4/8/19 3:44 PM, Austin S. Hemmelgarn wrote:
On 2019-04-08 07:27, Leonid Bloch wrote:
Hi List,
Can you suggest a way of cryptographically verifying the content of a
btrfs subvolume, besides the naïve approach, of running a cryptographic
hash function on the output of btrfs send?
Running BTRFS on top of dm-integrity and dm-crypt with them set up to
provide AEAD-style encryption comes to mind as an option, and would
actually provide a much higher level of verification than just verifying
the content of a subvolume (it will verify the entire filesystem).
Thanks! That's actually a good point, I would like to verify a specific
subvolume(s), while on others the content can change.
That's a good point cause it shows that I was wrong assuming that btrfs
scrub would help - it will scrub the entire filesystem as well, and
compare checksums internally, which is not what I want - I want to
compare to some external checksum. Sorry for the confusion there.
If your primary goal is to just verify that nobody has changed the
contents of the subvolume, then even hashing the send stream may be
problematic for your use case. Certain differences in the on-disk layout
of the data (which could be caused by deduplication or defragmentation)
result in changes in the send stream, but don't actually change anything
from the perspective of userspace. Similarly, the send stream protocol
has changed slightly over time in backwards compatible ways, and such
changes may happen again in the future, so even if the on-disk layout is
identical, the hash may visibly change.
