On Sat, Sep 17, 2016 at 10:12 AM, Anand Jain <[email protected]> wrote:
> btrfs keeps it only in-memory and key hash goes to the disk. > Further in the long we need an integration with key management > system as well. Maybe LUKS2 is usable for this part, and still adaptable since it's not finished yet? It looks to me like essentially unlimited keyslots compared to the current 8. You don't really care about the dm-crypt part of it, but the key management part of it, perhaps. Both the original and new subvolumes initially share one DEK that go with the shared encrypted extents, but upon snapshot happening the new extents in each subvolume need their own DEK. Policy wise these DEKs can be wrapped in the same or separate passphrases or KEKs, as there could be hundreds or thousands of DEKs that apply to the many possible shared encrypted extents in a subvolume. If that's true, then it's an explosive number of keys per subvolume potentially. It doesn't depend on space as much as it depends on fs lifetime Otherwise I don't see how this is different than using a single DEK across all company hard drives. Compromise one, you've compromised them all. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
