Data Integrity

One of the possible CloudFS 2.0 features that I forgot to mention in my post yesterday, and which was subsequently brought to my attention, is the addition of data-integrity protection using checksums or similar. Some people think this is just part of encryption, but it’s really more than that. This same kind of protection exists at the block level in the form of T10 DIF and DIX, or at the filesystem level inside ZFS or btrfs, and none of those were developed with encryption in mind. The basic idea behind all of them is that for each data block stored there is also a checksum that’s stored and associated with it. Then, when the block is read back, the checksum is also read back and verified as correct before the data can be admitted to the system. The only way encryption enters the picture is that the integrity check for a given data block has to be unforgeable, which implies the use of an HMAC instead of a simple checksum. This protects not only against random corruption, but also against a targeted attack which modifies both the data and the associated HMAC (which might be equally accessible to an attacker in naive designs, though our design is likely to avoid this flaw). Thus, we need three things.

  • A translator (probably client-side) to handle the storage of checksums/HMACs received from its caller during a write, and also their retrieval – but not checking – during a read.
  • A translator that generates and checks simple checksums for the non-encrypted case.
  • Enhancements to the encryption translator to generate and check HMACs instead.

Another possible implementation would be to implement all of the code inside the encryption translator, and simply have an option to turn actual encryption off. Such a “monolithic” approach is unappealing both for technical reasons and also because it would preclude offering the data-integrity feature as part of GlusterFS while keeping encryption as part of CloudFS’s separate value proposition.

If you think this kind of data-integrity protection would be important enough for you to justify making it part of CloudFS 2.0, please let me know. It’s much easier to make a case that Red Hat (or Gluster) resources should be devoted to it if there’s a clear demand from people besides the project developers.