There has been some discussion earlier about using LUKS as the basis for
the file format encryption, and after some consideration I'm leaning
towards not doing so. There are basically three reasons for this:

1) There is no widely used Python implementation of LUKS, so we would
use a custom implementation contributed by John Lenz. It is much more
difficult to make sure this implementation is secure and without any
backdoors or bugs than to simply write my own algorithm.

2) The LUKS format seems a bit overkill for what is required for
Revelation (for example, it supports using 8 different passwords for the
same file).

3) The LUKS format doesn't have any satisfactory ways to include
arbitrary data in the header, such as a magic string for identification.

Instead I will most probably use an algorithm based on the PKCS #5 (RFC
2898) recommendation, using AES-256 for encryption and SHA-256 for key
generation. The data will be prepended with a fixed-length header
containing necessary data such as the CBC initialization vector, the
salt, the number of hash iterations, and a magic string to make the file
format recognizable. This will make it a bit harder to access the file
with other tools, but I will include a command-line option for
decrypting a data file at a later time, and it is quite easy for a
third-party to write a decrypter as well.

Any comments?

Erik Grinaker <[EMAIL PROTECTED]>

"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about."
                                                  -- Albert Einstein

Reply via email to