Encrypted filesystems

[David Kramer]

Kent Borg wrote:
> That does bring up another reason for encrypting data: To maybe make
> it possible to do warranty returns on dead disks that were used to
> store sensitive data.
> 
> And you make a good point: Neither encrypted data nor keys have to be
> military quality to be useful.  No more than the locks on my house
> have to be Fort Knox-quality to be useful.  
> 
> 
> -kb, the Kent who tries to be capable of spotting dangers without
> being dangerous.

I ended up writing my own solution, partly because I could not find exactly 
what I wanted elsewhere, and partly because I wanted something portable 
enough to work not only on my Linux boxen, but also on my Zaurus PDA and 
Windows.

The program I wrote uses a series of reversible algorithms in series (i.e. 
if you run  input > x() | y() | z() > output, you can get the input back by 
running "input > z() | y() | x > output"), and one or more of those 
algorithms has a passphrase as an input.

This gets me everything I need in an encryption program (which is not as 
good as the encrypted filesystem, but has other advantages).

- Since a passphrase is incorporated into one of the algorithms, even if 
they got the source code (which I now have encrypted with GPG), and even if 
they knew the algorithms, it would still take serious muscle and probably a 
few days to brute force decrypt it.

- The output is the same size as the input, and the file is modified in 
place, so there's no temporary decrypted copy to wipe.

- The algorithms are piped one to another, so all of the work is done in a 
single pass though the input, making it run pretty fast.


However, when I was installing SuSE 9.3 yesterday, I noticed that it has 
filesystem (file-based and partition-based) encryption.  I will look into 
that after install, though, because they installer tells you NOTHING about 
what their encrypted filesystem really is, and neither does the manual that 
came with it.  Sounds like a good question for their mailing list.