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]> http://erikg.codepoet.no/ "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
