... Center¹

This work was done at the HP Systems Research Center in Palo Alto. The authors with differing current affiliations are: Andersen, MIT; Burrows and Thekkath, Microsoft Research; Mann, VMware.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... blocks²

For simplicity, this example assumes that the file's blocks can be described using only one capability; in practice, highly fragmented files may require multiple capabilities because capabilities have a fixed size so that they can fit in a packet.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...³

The reader might be wondering whether the application of a MAC to its own output has somehow compromised its cryptographic properties. This is not the case, and the intuitive argument is as follows: Suppose that it was feasible for an adversary who does not know the value of $k$ to produce values $m$, ${\it op}$, and $c$ such that $m=h({\it op},h(c,k))$. Then by the unforgeability property of $h$ mentioned above, the adversary must know the value of $h(c,k)=s$. Thus, the adversary can produce $c$ and $s$ such that $s=h(c,k)$. Therefore, by applying the unforgeability property again, the adversary must know the secret key $k$, a contradiction.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... ID.⁴

Note that the group ID's cannot be recycled, which means that in theory the system will eventually run out of space. But by using relatively few bits for the group ID's--say 64 bits--it will take longer than the life of the system for that to happen.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... NFS.⁵

A higher level of consistency could be implemented using the same basic technique as Spritely NFS [24]: channeling reads and writes for non-exclusive-mode files through the metadata server.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... protocol.⁶

We would store blocks encrypted on disk, but the keys would be managed by the metadata servers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.