I guess it could be done with a single bit. One value of the bit would be "the default class key for this dataset" and the other value would be "different classkey -- find class key ID in the extended attribute".
How precious is space? I doubt if we'd ever really need more than, say, 2 bytes' worth of class keys (a class for each expiration date, with granularity of a day for up to 30 years would only be 10,000 keys). So 2 bytes for specifying the class ID would seem to be sufficient. And, as I said, although it's a minor advantage to have a unique key K chosen for the data for each file (and store K encrypted with the class key in the dnode), which would take another 128 bits or so to store the encrypted file key), if space was very limited, we could do with *only* storing the 2 byte class key in the dnode, and encrypt all the files in the same class with the same class key. Radia Nicolas Williams wrote: > I think we need to make sure that there will be at least one bit in the > dnode reserved for this when the i-team gets around to implementing > per-file keying. Additional data could always be stored in an extended > attribute if need be. >
