* "Travis H." <[EMAIL PROTECTED]> wrote: > 1) In the paper, he mentions that the state file could be altered > by an attacker, and then he'd know the state when it first came up. > Of course, if he could do that, he could simply install a trojan in > the OS itself, so this is not really that much of a concern. If > your hard drives might be altered by malicious parties, you should > be using some kind of cryptographic integrity check on the contents > before using them. This often comes for free when encrypting the > contents.
Agreed; but regarding unix systems, I know of none crypto implementation that does integrity checking. Not just de/encrypt the data, but verify that the encrypted data has not been tampered with. A however unlikely and far-fetched analogy would be someone altering an encrypted root fs so that f.e. /etc/hosts.deny would decrypt differently. Such things tend to stay unnoticed when not some kind of IDS is used, for the very fact that all the common (more or less skillfully crafted) crypto implementations simply fail to do integrity checking; dm-crypt, loop-aes, mainline cryptoloop, truecrypt, bestcrypt, CrossCrypt, ... However, though preventing the unnoticed modification of an encrypted device is undoubtedly a goal to strive for, this is not what those crypto implementations try to achieve. They just work towards safely and reliably de/encrypting one's data; some more, some less. -- left blank, right bald still, loop-aes is the way to go.
pgptJQI7AL3Qv.pgp
Description: PGP signature