Cryptography Reference
In-Depth Information
today, but there is rather complex software behind them. It is instructive to
analyze a simpler package that also shows the typical problems.
CFS
(
Cryptographic File System
) was developed by Matthew Blaze from
1992 onwards. We know Blaze from the attack against the Clipper chip protocol
(see Section 6.4). CFS Release 1.3.3 can be found on our Web site. CFS Release
1.3.3 consists of roughly 8500 lines of source code and is used on some UNIX
systems, mainly BSD and SunOS variants, but also AIX by IBM, HP/UX,
Irix, Solaris, and (with problems) Linux. Its quality lags behind that of SSH:
it is not written in a particularly portable and efficient way, its installation
is cumbersome, and the encryption methods used are fixed on 64-bit block
algorithms. I couldn't test it myself, but I know that CFS reduces performance
considerably. This is the price to be paid for security, which sometimes appears
to be higher than that for SSH.
CFS uses the Network File System (NFS) mentioned in Section 7.3 from within
UNIX. The latter embeds file trees in remote computers such that they virtually
reside on your own hard disk. With CFS, the file trees actually reside on your
own disk, except that the data on their way from and to the file system are
encrypted. That doesn't change anything, either for the application or for the
user. The only thing is that the user has to use the
cattach
command to 'attach'
a file tree into the current hierarchy before starting to work. To 'detach' the
file tree, he uses
cdetach. cattach
requests a password. Outsiders won't even
recognize file names, let alone file contents. That's not all, but we are interested
in cryptology rather than in UNIX.
Encryption with Some Particularities
Things are not as simple as they may appear. Disks cannot be encrypted as
you would encrypt files: they need to remain freely accessible. For example, a
program has to be able to read the 34th, the 666 231st, and then the 11 004th
byte from a file without getting into trouble. However, encryption is generally
sequential, except in ECB mode and stream ciphers. But the latter don't allow
you to hold a sufficiently long key stream in spare. For one thing, this stream
would have to be at least as long as all confidential data together — that causes
capacity problems. Second, computing it in advance would cost much time.
And the simple ECB mode is too insecure. Now what?
Blaze had a simple and good idea to solve this problem [BlazeCFS]. Though he
creates a key stream, that stream has a length of only 256 Kbytes (rather than
128 Kbytes as stated in the README file). After XORing the entire stream
