Performance

In this section we present the overall TCFS performances analysis as a proof of concept.

We have employed a modified version of the Andrew benchmark [7]. The benchmark takes as input a subtree containing the source code of a UNIX application (in our case we used the sources of the GNU make application). The benchmark consists of five phases:

1. Directories creation: the source directory hierarchy is reproduced several times into a target directory on the tested file system.
2. File copy: all files of the source directory are recursively copied to a directory of the target subtree.
3. Recursive directories stats: attributes of each file in the target subtree are recursively scanned.
4. Recursive files scan : recursive reading of files in the target subtree.
5. Compilation: files on target subtree are compiled and linked.

We have performed four suites of tests. The first suite measured the performance of NFS. In the second suite of tests, we measured the performance of TCFS on files that are not encrypted. Thus, input/ouput is still performed by TCFS but no encryption engine is invoked. The last two suites deal with TCFS in which encryptions is performed by the NULL module (encryption using the indentity function) and the 3DES module (encryption using Triple-Des[16]). TCFS with the NULL module differs from the second test suite as here an encryption engine, albeit a trivial one, is invoked.

All tests have been performed on a Pentium II at 233MHz with 64Mb of memory. We have performed two series of experiments. In the first series the results obtained were more influenced by the performance of write operations as we had the the source tree on a local filesystem and the destination files on the remote filesystem (TCFS with 3DES, TCFS with Null, TCFS without encryption and NFS). In the second series of experiments we did the opposite: the source tree was on the remote filesystem and the destination filesystem was a local filesystem. Thus, the measurement were mainly affected by the performance of a read operations.

The figures reported are the average of 10 runs with the client and the server running on the same machine so that network latency is not an issue in the measurement.

As it is obvious from the experimental data, reading is much faster than writing. This is due to the fact that, unless a whole new block is written, a write operation involves reading a block, decrypting it, modifying it and re-encrypting it. Moreover, TCFS does not perform very well at random accessing encrypted files. Since TCFS encrypts each block using CBC, reading one byte might involve decrypting a whole block considerably slowing down the operation. This however does not have to be considered an inherent limitation of TCFS as it only depends on the specific cryptographic engine employed. Much faster random access can be obtained by encrypting in ECB (Electronic CodeBook) mode even though in this case the confidentiality of the data is considerably weakened.

The overhead introduced by TCFS can be seen by comparing the first column with the second and the third column of Figure 4. As it can be seen, TCFS NONE exhibits performances very similar to NFS. More surprisingly, TCFS NULL is much slower than NFS. This is due to the folowing phenomenon. TCFS forces the remote attribute checking before each read/write operation whereas NFS does not. We expect that removing this check would have no impact on the security and keep the performance of TCFS NULL test much closer to NFS.

TCFS 3DES is the slowest of all and this is mainly due to the time to perform encryption/decryption. Indeed the difference between TCFS 3DES and TCFS NULL is exactly the overhead introduced by the cryptographic engine. Reducing this gap calls for a better cache management strategy, an issue that at the moment has not been considered yet. Also, we stress that when this test were performed with client and ``remote'' filesystem residing on the same machine. On a loaded Ethernet, the encryption/decryption overhead is likely to be absorbed by the network latency.

We believe that TCFS still has room for improvement (we would like to see TCFS NULL closer to TCFS NONE) but at the moment its performances are acceptable.

Figure 4: Performance of the TCFS Linux implementation as measured with the Modified Andrew Benchmark