Messages in this thread |  | | Date | Wed, 8 Jan 1997 23:11:02 -0800 | Subject | Re: signing a filesystem | From | tytso@mit ... |
| |
OK, I've been keeping quite on this thread for a while, but there have been a number of wrong assertions which I want to correct:
> 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.
Incorrect. Integrity and Data Confidentiality are different things, and it's a bad assumption that Data Confidentialty automatically implies that you have Integrity. Just to give a simple example, suppose your encryption algorithm is DES OFB. This provides good Data Confidentialiity (or as good as DES will give you), but if you know the plaintext, you can XOR away the known plaintext, and then XOR in new values. This is just a simple example of a scheme can provide data confidentialty, while not providing any protection against modification in the face of known plaintext.
Cryptographers have long advised that Integrity and Data Confidentialty be considered separate services, provided by separate algorithms, and indeed using different cryptographic keys. (That way a break in the key providing data confidentiality doesn't compromise your data integrity.)
More generally, I have to ask the question why are we trying to do cryptography at the filesystem level at all? What is your threat model? Who are you trying to protect your data against? What sort of resources is your adversary going to have?
It is not at all clear to me that the filesystem is really the right place to be doing this sort of protection. Since the integrity protection and signing is taking place in the kernel (and the cryptographic keys have to present in the kernel at all times while it is running), this scheme doesn't protect you against someone who has managed to get superuser access. It only protects you against someone who has physical access to your disk while the kernel isn't running. However, is this a threat model which is most people will commonly see?
- Ted
|  |