The client host mounts the remote filesystem as a TCFS filesystem (by means of a patched version of mount). Client and server communicate by means of NFS protocol. The user provides the encryption key to the TCFS client so to allow encryption and decryption of files. The TCFS server instead is a simple NFS server: it needs not to know that the exported filesystem is indeed a TCFS filesystem. This has the advantage of making possible to use TCFS on any host that runs an NFS server.
User-level applications passes keys and directives to TCFS by calling the system call ioctl on the filesystem's mount point; for this pourpose, TCFS introduces some new ioctl commands.
Since version 2.0, the Linux kernel features Loadable Kernel Modules (LKM) (see [1] and [11]). LKMs consist in some parts of the kernel (usually device drivers or filesystem switchs) which can be loaded at runtime whenever they are needed. Cryptographic services, in TCFS, are implemented as kernel modules. Thus, ciphers can be selected at runtime by loading the proper dynamic kernel module. Users can choose different ciphers to encrypt/decrypt different files or directories. Each cipher module is completely independent from the others and it is possible to load, unload different engines or even to use simultaneousely several cryptographic engines.
The Linux TCFS implementation allows to have client and server running on the same host. However, the communication between the two takes place using the NFS protocol. This has the drawback of slowing down the communication.