Re: safety of encrypted filesystems
also sprach martin f krafft [EMAIL PROTECTED] [2005.06.17.0944 +0200]: also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.0857 +0200]: And also, when you write any block, you have to reencrypt all the remaining blocks. Yes, don't you? From all I can tell, this is the case for EBC and CBC, but symmetric cryptography is fast enough these days for this not to be a problem. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! an avocado-tone refrigerator would look good on your resume. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
On Wed, 22 Jun 2005 at 06:32:08PM -0400, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: You could always run tripwire on the mounted file system, unmount it, change your block, remount it, and run a tripwire check. This should identify *WHICH* file changed. he has only one file and this was unaltered, the question is why. Perhaps the block that was changed was a free block? -- Phillip Hofmeister -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 at 06:01:02AM -0400, martin f krafft wrote: also sprach Horst Pflugstaedt [EMAIL PROTECTED] [2005.06.17.1018 +0200]: encrypt /dev/hda7, mount, fill it with some hundred small files (with known content), unmount, change one bit/byte/block on /dev/hda7 (using dd), remount, look for the remaining files and their contents. I've tried that and the filesystem mounts without error. I have not yet figured out where the corruption occurs. You could always run tripwire on the mounted file system, unmount it, change your block, remount it, and run a tripwire check. This should identify *WHICH* file changed. -- Phillip Hofmeister pgpFA0uNAsSYs.pgp Description: PGP signature
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: You could always run tripwire on the mounted file system, unmount it, change your block, remount it, and run a tripwire check. This should identify *WHICH* file changed. he has only one file and this was unaltered, the question is why. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, Jun 17, 2005 at 12:59:14PM -0700, Ben Pfaff wrote: martin f krafft [EMAIL PROTECTED] writes: However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? Yes and no. If you change the first block in a set of CBC-chained blocks, the last block will change. But to recover the contents of the last block, you only need the last block and the preceding block (and the key). A good explanation of this mode (dubbed Sector Enciphering Operation) is in Saarinen's paper about the watermark weakness[1]. cryptoloop and siblings basically use CBC only within a sector (512 byte), so different sectors are all independent from each other. cheers, Max [1] http://docs.indymedia.org/twiki/pub/Local/UkCrypto/wisa2004.pdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Bernd Eckenfels [EMAIL PROTECTED] [2005.06.18.0253 +0200]: have you unmounted the file before writing to it? perhaps you changes was overwritten with the blok from cache Yes. And my simulated broken blocks were still there after checking the integrity and unmounting again. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! drink canada dry! you might not succeed, but it *is* fun trying. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
* martin f. krafft: Encrypted filesystems are hip these days, [...] Are they? I thought most of the fuzz was about encrypted block devices. If such a bad block occurs and renders a small part of the encrypted file unreadable, wouldn't the entire partition and all its data be effectively destroyed? A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). By the way, the very fact that the block is not lost completely indicates a major cryptographic weakness: there are no integrity checks at all. (The constant IV problem is another one.) These weaknesses don't matter in many scenarios, but it's still an undesirable situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0834 +0200]: Encrypted filesystems are hip these days, [...] Are they? I thought most of the fuzz was about encrypted block devices. That's what I mean. If such a bad block occurs and renders a small part of the encrypted file unreadable, wouldn't the entire partition and all its data be effectively destroyed? A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! DISCLAIMER: this entire message is privileged communication, intended for the sole use of its recipients only. If you read it even though you know you aren't supposed to, you're a poopy-head. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
* martin f. krafft: A corrupt sector corrupts the remaining part of the block. Block sizes are much smaller than 1 GB because when part of a block is changed, all the following bytes have to be rewritten (if a reasonable the cipher mode is used). Of course blocks are small, e.g. 64 bytes. These are *cipher* blocks, and they are chained only within a *block device* block. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 08:46:03 +0200 martin f krafft [EMAIL PROTECTED] wrote: Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? No. If it would be that way, it would allways be necessary to decrypt the whole filesystem, when you want to read the last block. Or you have to store a decrypted version in memory... And also, when you write any block, you have to reencrypt all the remaining blocks. I don't know, what kind of CPU you use, but on my system, that would be really time consuming!!! The loss of a single block on a harddist should be protected by using some kind of forward error correction like the Solomon-Reed one. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! friendships last when each friend thinks he has a slight superiority over the other. -- honor de balzac signature.asc Description: Digital signature
Re: safety of encrypted filesystems
* martin f. krafft: also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? For each device block, a constant, block-specific IV is used. Device blocks are not chained together. The block device doesn't know anything about files, anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:03:57 +0200 martin f krafft [EMAIL PROTECTED] wrote: Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? That is the reason, why a reasonable clever programmer would not do such a silly thing. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:02:05 +0200, martin f krafft writes: also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0835 +0200]: no - with cbd, dud blocks effect only decryption of the block itself and the one directly following it. ... and that one affects the one directly following it, and that one affects the one directly following it. no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. one dead block spills junk all over the block+1 when decrypted, but the (undamaged) encrypted block+1 is used to decrypt block+2 and so on. So if you have a corruption in the first block, your data are gone. If you have a corruption in the last block, the loss is minimal. no, see above. details (with a nice diagram) can be found on page 220 of the handbook of applied crypto. the official pdfs are here: URL:http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf regards az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpE1r4HTynPz.pgp Description: PGP signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 17:15:32 +1000, Alexander Zangerl writes: (bloody hell: can't even type anymore. weekend is calling...) also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0835 +0200]: no - with cbd, dud blocks effect only decryption of the block itself and the one directly following it. i meant cipher block chaining. no idea how i got to cbd. details (with a nice diagram) can be found on page 220 of the handbook of applied crypto. the official pdfs are here: URL:http://www.cacr.math.uwaterloo.ca/hac/about/c hap7.pdf page 229. argh. az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpy13gk1dyRq.pgp Description: PGP signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 17:15:32 +1000 Alexander Zangerl [EMAIL PROTECTED] wrote: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. That's a possible, but unsecure way to do that. This way, an attacker can try to decrypt any block x by using the encrypted block x-1 and guessing the passphrase. When knowing the structure of the filesystem, he will have a chance to find the passphrase in a reasonable time. When an attacher HAS TO decrypt the first block of a filesystem, AND this filesystem starts with a challenge (random data) in the first block and the real filesystem begins at the second block, there is no way to guess the passphrase, because the attacker cannot check, if the first block was decrypted correctly. If i had to build an encrypted filesystem, i would use clusters of i.e. 8kb, starting with a challenge (256 bytes), followed by data (7.5 kb), followed by error correction data (256 bytes). On every write, the first 7 3/4 kb will be encrypted and then the error-corrction code will we calculated for that data and stored in the last part of the cluster. I think, this will give good security with reasonable CPU-effort. -- mit freundlichen Gruessen / with friendly regards Michael BuchholzPhone.: +49 231 4755513 Paschknappstr. 13 Mobil.: +49 171 3111861 44265 Dortmund, Germany Fax...: +49 231 4755514 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.0857 +0200]: If it would be that way, it would allways be necessary to decrypt the whole filesystem, when you want to read the last block. Or you have to store a decrypted version in memory... No, it would not. You only need access to the immediately preceeding block, since its *cipherdata* are used to encrypt the current block. And also, when you write any block, you have to reencrypt all the remaining blocks. Yes, don't you? I don't know, what kind of CPU you use, but on my system, that would be really time consuming!!! Just one of those 100 GHz low-end consumer products with 128 cores. And you? :) The loss of a single block on a harddist should be protected by using some kind of forward error correction like the Solomon-Reed one. But *is* it? Before I put my data into a cipher file, I sure as hell want to know... What I find a bit peculiar: I have made an 8Mb test file in fs.img, and I overwrite a small part of it: (dd if=fs.img bs=1 count=1; dd if=/dev/urandom bs=1 count=8; dd if=fs.img bs=1 skip=10008) | fs2.img When I mount fs2.img, I get no error... what gives? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! #include signature.h signature.asc Description: Digital signature
Re: safety of encrypted filesystems
also sprach Alexander Zangerl [EMAIL PROTECTED] [2005.06.17.0915 +0200]: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. one dead block spills junk all over the block+1 when decrypted, but the (undamaged) encrypted block+1 is used to decrypt block+2 and so on. Ah, yeah, this makes perfect sense. I *knew* it even. I simply failed to see the big picture. So encrypted block devices are not really more dangerous than clear-text in the end... I suppose with AES you end up losing at least 64 bytes of data, which could be less without encryption... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! always remember you're unique, just like everyone else. signature.asc Description: Digital signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 09:36:07 +0200, Michael Buchholz writes: On Fri, 17 Jun 2005 17:15:32 +1000 Alexander Zangerl [EMAIL PROTECTED] wrote: no, this is subtly wrong. the *encrypted* block affects the decryption of the block following it, not the cleartext block. That's a possible, but unsecure way to do that. please note that i was talking about encryption algo blocks, not filesystem blocks. what i've outlined is just the normal way cbc is implemented - which is what martin asked about. how far you chain is up to the implementer of a crypto fs; and of course there are pros and cons for chaining globally vs. chaining just a few crypto blocks into a single fs block. regards az -- + Alexander Zangerl [EMAIL PROTECTED] DSA 0xF860ACF1 + + Bond University IT School phone +61 7 5595 3398 + pgpHFH4Et7vjO.pgp Description: PGP signature
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? It is therefore better to use counter mode for clusters. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
On Fri, Jun 17, 2005 at 09:03:57AM +0200, martin f krafft wrote: also sprach Florian Weimer [EMAIL PROTECTED] [2005.06.17.0848 +0200]: These are *cipher* blocks, and they are chained only within a *block device* block. Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then CB_last will indirectly depend on CB_first. If the data are large enough to span multiple block device blocks, damage to the beginning of the cipherfile makes the rest of the file unusable, no? wouldn't it be possible to test that? Scenario: encrypt /dev/hda7, mount, fill it with some hundred small files (with known content), unmount, change one bit/byte/block on /dev/hda7 (using dd), remount, look for the remaining files and their contents. I can imagine this might work; errors dont' have to be implemented in hardware, do they? Greetings Horst -- ... I don't know why but, suddenly, I want to discuss declining I.Q. LEVELS with a blue ribbon SENATE SUB-COMMITTEE! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: So encrypted block devices are not really more dangerous than clear-text in the end... I suppose with AES you end up losing at least 64 bytes of data, which could be less without encryption... You lose much more with RAID-5, yes. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Horst Pflugstaedt [EMAIL PROTECTED] [2005.06.17.1018 +0200]: encrypt /dev/hda7, mount, fill it with some hundred small files (with known content), unmount, change one bit/byte/block on /dev/hda7 (using dd), remount, look for the remaining files and their contents. I've tried that and the filesystem mounts without error. I have not yet figured out where the corruption occurs. It's an 8M filesystem (twofish) and I put an 8M file of all zeroes in there. After unmounting and deleting the loop device, I overwrote four bytes in the file with . Saving, setting up the loop devices, mounting... no errors. **And the file is still all zeroes...** So I guess there is error correction happening? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! work consists of whatever a body is obliged to do. play consists of whatever a body is not obliged to do. -- mark twain signature.asc Description: Digital signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 12:01:02 +0200 martin f krafft [EMAIL PROTECTED] wrote: devices, mounting... no errors. **And the file is still all zeroes...** So I guess there is error correction happening? Is there something in the logfiles? Maybe the cryptoloop is a little verbose about errors... -- mit freundlichen Gruessen / with friendly regards Michael BuchholzPhone.: +49 231 4755513 Paschknappstr. 13 Mobil.: +49 171 3111861 44265 Dortmund, Germany Fax...: +49 231 4755514 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.1218 +0200]: Is there something in the logfiles? Maybe the cryptoloop is a little verbose about errors... Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! there's someone in my head but it's not me. -- pink floyd, the dark side of the moon, 1972 signature.asc Description: Digital signature
Re: safety of encrypted filesystems
fre, 17 06 2005 kl. 12:30 +0200, skrev martin f krafft: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? Right. Files are only sparse if you seek to somewhere in the file and start your writing there. The empty space reads as \0's, but just writing \0's won't give you a sparse file. -- Salu2, Sren. smime.p7s Description: S/MIME cryptographic signature
Re: safety of encrypted filesystems
On Fri, 17 Jun 2005 12:30:58 +0200 martin f krafft [EMAIL PROTECTED] wrote: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with dd if=/dev/zero of=file bs=8M count=1 right? Right. This file contains 2^23 0x00's. The other thing, mentioned, will happen with this code: fd = open (empty_file, O_WRONLY, 0666); lseek (fd, 2^23, SEEK_SET); write (fd, ?, 1); close (fd); ls -l will show 8 MB du -a will show 1k Maybe, you'll like to try bigger damages to the encrypted fs, until the error correction breaks. And maybe, fill the file in the fs from /dev/randon instead of /dev/zero. -- mit freundlichen Gruessen / with friendly regards Michael Buchholz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
also sprach Michael Buchholz [EMAIL PROTECTED] [2005.06.17.1242 +0200]: fd = open (empty_file, O_WRONLY, 0666); lseek (fd, 2^23, SEEK_SET); write (fd, ?, 1); close (fd); dd if=/dev/zero of=file bs=1 count=1 seek=8388607 -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! durch frauen werden die hhepunkte des lebens bereichert und die tiefpunkte vermehrt. - friedrich nietzsche signature.asc Description: Digital signature
Re: safety of encrypted filesystems
martin f krafft [EMAIL PROTECTED] writes: However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? Yes and no. If you change the first block in a set of CBC-chained blocks, the last block will change. But to recover the contents of the last block, you only need the last block and the preceding block (and the key). -- I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility. --Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
In article [EMAIL PROTECTED] you wrote: Nope. Someone raised the point of a file with all zeroes being possibly sparse, but I don't think that's the case if I wrote it with have you unmounted the file before writing to it? perhaps you changes was overwritten with the blok from cache -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
