On Sun, Nov 26, 2000 at 03:57:45PM +0000, Marc Mutz wrote: > John Kennedy wrote: > <snip> > > At what point is someone going to get burned? I started out looking > > into it as a security and anti-tampering system -- even if someone did > > have physical possession or access to the hardware, it wouldn't do them > > a lot of good without a LOT (hopefully horribly prohibitive) of work. > > How many bits do I have to give them before my effort is all for naught? > <snip> > > In short: None. I think you're missing my point, but you come around to it, below. > Long version: That is because you make the common mistake of > Q> encryption == integrety. > That is not so! The right equality is: > Q> encryption == confidelity. Well, no I didn't but I didn't say that in the email. It isn't like we're talking digital signatures here, but the inability to change blocks on the disk without garbaging it comes close. I do get your "encryption == confidentiality" point though. > You said, you wanted security and tamper-proofness. You got nothing of > that, since anyone could substitute blocks. If you want a system that is > tamper-proof, start by installing tripwire ... I'm looking at AUGMENTING tripwire-like security, not replacing it. I'm exploiting the encryption, taking advantage of the fact that improperly encrypted blocks will yield garbage instead of compromised data. Yes, I'm sort of abusing the cryptography to achieve this goal. It is a whole lot easier dealing with garbaged data than tampered data. > It is of course right that given an encrypted disk it is computationally > infeasible (at least to the extent known to the public) to make a > _subtle_ change. Poking around encrypted blocks and changing some of > them will in general yield garbage. But the point is that, given that > garbage, you cannot deduce from that whether the ciphertext has been > tampered with or the garbage was there before encryption took place. Yes, this is what I'm exploiting. I'm looking at potential garbage as a denial-of-service. Tampering can be far worse, but I'm digressing again. > So, I _guess_ that you want not only integrety-checking, but also > confidelity. Serpent-encryption will buy you that. It is probably the > most secure cipher known to the public at this point. But if you want > integrety, then you should additionally install tripwire, read the > Security-HOWTO and B. Schneier's Applied Cryptography. Bingo, exactly. Using tripwire or equivalent to augment. I think this negates your short answer though. Which sort of gets us back to my original question. I have an encrypted filesystem that an attacker will have to get through before they can get at the data that is on it. They don't know the password, but they have a statisticly good idea of what some of it is (primarily the superblock, with a lot of the information contained in it being based on the partition size, etc). I'm sort of looking for an experience-based answer off of the top of your (or anyone's) head, but we're mixing generalities with math and crypto (not a good combo). I'm wanting to know how much encrypted- knowntext you would need to really compromise the serpent password, which would let you turn around and compromise the rest of the disk. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
