Aren't you contradicting yourself here? I don't mean to be rude, but you've managed to confuse me ;)
You say: >If you used TrueCrypt for this, it would not have to work on top of a >file system. But isn't there always, in any case a filesystem? Which completely or in parts gets encrypted/decrypted by the encryption layer? Then you say: >/dev/your_usb_drive_here and then format it with your file system of >choice (go ext2 if you're comfortable with using the Windows driver >that implements it;) This seems contradictory... As I understand it, I can either have just an encrypted disk, meaning that one or all partitions can be encrypted, with say dm-crypt (or truecrypt). As long as the underlying fs is supported. Or I can use full disc encryption. Which depending on implementation also encrypts all metadata, including the mbr of the disk. For this the fs does not necessarily have to be supported within the encryption layer?! But no matter what I do, I still when decrypting 'find' a filesytem that needs to be supported by my os. Please correct me if I'm wrong! As mentioned somewhere else, I'll just split the disc, first a unencrypted ntfs partition, and then another encrypted partition (ext3 or 4 formatted). As this disc wont be accessed often, this will probably do just fine. If data needs to be moved to the encrypted ext partition, I can do that from linux if need be, and temporarily store it on ntfs. As this isn't anything really critical, and I'm not on the run, this much security lax wont harm, although obviously I'd try to avoid it. Regarding windows support for ext: Why don't you think much of it? I don't like the fact that the more well known implementation isn't opensource nor freesoftware, which the lesser known driver I'm using is. Sadly it seems not getting alot of attention these days. I've been using it for ages now, sofar no problems, performance (read only) is ok. I haven't dared go near write support though... Tom
