TCFS: Transparent Cryptographic File System

A description of how the TCFS secure file system works and why you should use it.
An Example

Suppose you have a server named foo and a client named bar and suppose you export the directory tree named /exports from server foo to client bar. For this to be true foo must have the following line in /etc/exports:

/exports       bar(rw,insecure)

Now, login as root on bar and mount /exports by typing:

mount -t tcfs foo:/exports /mnt/tcfs
This command causes the remote file system, /exports@foo, to be mounted on the local file system, /mnt/tcfs@localhost, via a TCFS layer.

Now, suppose your login is usdm1, and you own a directory named /mnt/tcfs/usdm1. Login as usdm1 on bar and execute tcfslogin; doing so enables you to use encryption in your directory /mnt/tcfs/usdml. If tcfslogin is not issued, a permission denied error will be issued when attempting to access files with the X flag set.


In order to evaluate the overhead introduced by encryption of the data sent over the network, we performed a set of tests. We ran the test in the following framework:

  • The client machine running TCFS on the Linux 2.0.23 kernel is a Cyrix x686 166MHz processor

  • The server machine running as the NFS+xattrd file server is an Intel Pentium 133MHz processor with a 2GB fast SCSI disk.

Since encryption/decryption is a CPU-bound task, having a fast client to perform encryption results in better performance. TCFS makes use of standard VFS caches—no special caching is needed.

The real time values shown in Table 1 and Table 2 were obtained using the time command with the following options set for the read operations:

time dd bs=xxx if=file of=/dev/null count=n

and for the write operations:

time dd bs=xxx if=/dev/zero of=file count=n

The tables show the following results:

  • The overall performance of TCFS for write operations is close to NFS performances plus DES overhead. In the write, we suffer due to the lack of a cache system, since data are written directly to the server file system.

  • The performance of TCFS for read operations seems to hide part of the DES time, since VFS caches reduce server I/O.

  • Some extra cost is paid by TCFS for I/O of unencrypted files due to handling of extended attributes. In NFS several getattr calls are needed to update inode caching. In TCFS we need a getattr and a geteattr to update inode caching. This causes some extra overhead in TCFS I/O.

Use of other ciphers will result in different performances. We are planning to use IDEA, RC5 and other ciphers as optional modules for TCFS.


Ermelindo Mauriello ( was born in Avellino, Italy on December 10, 1972. He is a computer science student at the Dipartimento di Informatica ed Applicazioni “Renato M. Capocelli” of the Universita' di Salerno in Italy. He has been working on the TCFS project since 1995.