[lkml]   [1997]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: signing a filesystem
    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

     \ /
      Last update: 2005-03-22 13:38    [W:0.018 / U:70.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site