Re: signing a filesystem

Daniel G. Linder (dlinder@webcentric.net)
Fri, 3 Jan 1997 11:29:25 -0600 (CST)

On Thu, 2 Jan 1997, Andrew G. Morgan wrote:
> > Encryption addresses the proper concern. An encrypted file
> > cannot be modified without decrypting it first. Any attempt
> > to modify it in it's encrypted state is likely to render the
> > file useless rather than simply changing the data by making
> > it impossible to decrypt. Therefore, if you are running on
> > an encrypted file system, any attempt to modify the files or
> > filesystem meta-data from outside the avenues provided by
> > the OS will result in filesystem corruption. If file system
> > integrity *OR* security is important enough to care, it is
> > better to have to do a full filesystem restore if either is
> > suspect than risk the loss of either.
> This is not a flame. Don't get me wrong, encryption is marvelous. Use it if
> and where you can. But what if you can't? (Cross your fingers?)

I am assuming that you are meaning it can not be used leagly and/or those
who chose not to encrypt but just want the error detection that the
encryption would provide...

For those cases, maybe a filesystem "default" code could be used. Have
the default "password" for a filesystem be the same everywhere so if
no password is given then the system encrypts with the same password
EVERYWHERE. Even better if the encryption mechanism could be expanded to
allow for a certain string of characters to make the data
human-readable? Along the lines of what a "PASSWORD XOR (DATA + CRC) ==
ENCRYPTED_DATA" function would do when "PASSWORD" == 0. (Pardon me if my
cryptography is flawed -- it's been a long time since CompSci 200.)

Just for my sanity, I would probably have my main filesystem "protected"
with the CRC, and then make simple loop mount filesystems with the
password protection enabled on my personal system (which can be done
currently from what I remember). For higher security systems, I might go
with a minimal boot filesystem un-encrypted and then encrypt the
remaining filesystems.

Dan