On Wed, Jan 04, 2006 at 11:11:01PM +0100, knitti wrote: > my threat model includes the follwing two cases. for both of then svnd > can't protect me really well > > case 1) lets say someone can predict some blocks in my encrypted data, > then she can find every block (64bit) everywhere within the container > with the same data.
Of course not, that would have been true if it used ecb. It uses cbc which encrypts each disk block with an iv that depends on the block number, so a plaintext block will be encrypted differently depending both on which disk block it is in and what data precedes it in that block. > # vnconfig -ckv svnd1 /tmp/img1 [...] > # dd if=/usr/share/misc/license.template of=/dev/rsvnd0c bs=1k count=1 [...] > # cmp /tmp/img0 /tmp/img1 You are comparing the entire images. Try instead to fill one image with a repeating 8-byte pattern and then check the contents. The encrypted contents will not be repeated. > user key==encryption key==Bad Thing(TM) How would it help to generate a random key which is then encrypted with a user key and stored on the disk? A dictionary attack is still quite possible. While I'm here I'd like to ramble for a while about the fact that people seem to be obsessed with the ability to change their passphrases; I've seen it at least twice in this thread and sometimes I even hear people talking about changing the passphrase on pgp keys and similar. That only helps if you are sure noone has seen your previously encrypted key but now has been able to guess your passphrase and may in the future be able to access your encrypted key. See, if they already have a copy of the key encrypted with the old passphrase they will still be able to use your old passphrase on it. By reencrypting it with a new passphrase you only give them another chance to crack it. So changing the passphrase which is used to encrypt a key is stupid, you really need to generate a new key. So it will take a long time to reencrypt the disk, tough luck. The problem with user remembered passwords is that they aren't strong. The only way around that is to store a random number somewhere, e.g. a USB stick or a floppy. Therefore, you may want a combination of a stored random secret and some passphrase. You lose either => you lose your data. If someone finds the stored secret they can mount a dictionary attack or start extracting your finger nails. If you store the random secret on the disk itself it's a salt. While you can use a dictionary on it, it does mean that you have to do that for each disk you want to crack. So, salt + passphrase is good, and if you can store the salt wherever you want it's as good as you can do. > case 2) data integrity. I don't want, that a person can mess with my > data without knowing my key. the location of some data can be determined > on my disk, this data can be replicated everywhere else on the disk. [...] > classical replay attack. I seem to have screwed some block boundary, No. I don't know why you assume that ecb is used, the reason your output is messed up is cbc. It is possible to cut and paste encrypted data to some extent, but when you do that you will always mess up one crypto block. No way around that unless you find the key, so while this can be a problem it is a little less severe than you say. This is a problem with cbc, to avoid it you need to use another block chaining mode or add some integrity check. CGD also uses cbc according to http://www.imrryr.org/~elric/cgd/html4/cgd.html so unless there is some additional integrity check (which is a problem for block devices since it requires additional storage) it has the same problem. Andreas
