Re: Cryptographically verifying a btrfs subvolume

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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.