Cryptography Reference
In-Depth Information
To calculate the
vect
field, you fill the four least significant bytes with the file's
Inode number (a number that serves for unique identification of files) and the
four uppermost bytes with the file's modification time. Everything is then taken
and DES-encrypted using the 56-bit key (stripped of the most significant bits)
that was constructed from the
fixedkey
character string.
This little trick guarantees that no files with identical contents can produce
the same ciphers. Furthermore, the cipher of a slightly modified file never
resembles the file's previous version. From the cryptological point of view, the
DES encryption using
fixedkey
is even superfluous. The code apparently had
been changed in this place (
fhmkfileent()
function,
cfs fh.c
file), but not in a
consistent way. By the way, modern 64-bit UNIX systems wouldn't evaluate
the modification time, only the Inode number. This would be a critical security
flaw (slightly modified files can be recognized as such).
The important XORing with
vect
can be suppressed using the
−
l
switch for
cattach
. This is not a wise thing to do. This operation consumes minimal
resources, compared with the DES encryption, but its cryptological effect is
considerable.
The computation of the key streams
S
1 and
S
2 appears to be strange at first.
CFS encrypts the numbers 0 through 32 767 (2
15
1) in hexadecimal repre-
sentation in the ECB mode, where the highest digit is set equal to 1 when
computing
S
2:
−
S1 = {DES("00000000")
|
DES("00000001")
|
...
|
DES("00007FFFF")}
S2 = {DES("10000000")
|
DES("10000001")
|
...
|
DES("10007FFFF")}
This simple structure of
S
1 and
S
2 is certainly a welcome test condition for
owners of a DES Crack machine. With good algorithms, however, the risk is
smaller than it looks: this is the so-called
counter mode
we didn't discuss in
Section 5.1.1, but which is still considered to be secure. It is used in UMTS
and ZigBEE (and in the IEEE standard 802.15.4), among others.
CFS runs a continuous loop, which is aborted several times after a given time
for cryptographic random generation. Since more or less unexpected events can
occur in a multiuser system, there can be hardly predictable events (
truerand.c
file). The CFS author says that this method is pretty secure but slow, and it has
to be tested separately for every computer. This is risky, because errors intro-
duced from porting can remain undetected. There is a note in the documentation
about the
esm
Session Manager.
