Hi Chris,

Hi Anand,

Thanks for sending these out.  It's an important feature and I'm glad to
see it getting some love.

Right now, the design doc is really the most important part.  The
encryption side of things requires a layer of extra verification that we
can't get from reviewing the code alone.  We need to sit down with the
use cases and the workflow and make sure it meets all the requirements
of a secure system.


I'm the first to admit this needs a broader consensus than just
linux-btrfs@, and we want our reviewers to be able to go through things
without also having to understand every line of btrfs.


I do want to make sure that we can send/recv signed and encrypted
subvolumes, and be able to send them again unmodified.  This will end up
needing a revision of the send/recv protocol, but it adds a use case
wrinkle that we need to iron out in the design docs.

 Exactly. I have this in the requirement list. So I was hesitant
 to use any page(ext4)/sector(truecrypt) related IV. BTRFS just
 uses random IV which can be accessed through xattributes. But
 certainly has crypto issues. Anyway I will cover this in the document
 for the review by crypto experts.

I still prefer encryption at the subvolume level, but it's going to need
to be a superset of what is already possible with the vfs interfaces. If
we can do it with the existing interfaces, great.  If not we should be
adding features into the generic code where it makes sense.

 Sure Chris. Thanks for your comments.

- Anand


In this situation I was almost to drop the encrypted send/recv from my list, thanks for mentioning I shall keep that in the design so as of now as I did not use anything which is

To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to