Encrypted filesystems are hip these days, and that's good. One of
the reasons why I have not jumped on the waggon is a concern about
their safety.

When using a block cipher such as AES or similar to encode e.g.
a file of 1024 Mb, the blocks of the ciphertext are in relation to
each other. This is accomplished using methods like CBC (Cipher
Block Chaining, among others). The motivation here is to fend off
statistical (and replay) attacks.

Storage media these days are usually okay, but there have been times
when a bad block on a disk, or a corrupt byte on a flash medium have
caused trash to be returned for the block. Please correct me if I am
wrong, but with a single file spanning 1 Gb of medium, chances are
fairly high for such a bad block to happen within the file (given
that it happens at all).

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?

-- 
Please do not send copies of list mail to me; I read the list!
 
.''`.     martin f. krafft <madduck@debian.org>
: :'  :    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!
 
"ah, but a man's reach should exceed his grasp,
or what's a heaven for?"
-- robert browning

[ Post a follow-up to this message ]

* 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 debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0834 +0200]: 
> 
> Are they?  I thought most of the fuzz was about encrypted block
> devices.

That's what I mean.
 
> 
> 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 <madduck@debian.org>
: :'  :    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.

[ Post a follow-up to this message ]

* martin f. krafft:
 
>
> 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 debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Fri, 17 Jun 2005 08:46:03 +0200
martin f krafft <madduck@debian.org> 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 debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

also sprach Florian Weimer <fw@deneb.enyo.de> [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 <madduck@debian.org>
: :'  :    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

[ Post a follow-up to this message ]

* martin f. krafft:

> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0848 +0200]:
 
>
> 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 debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

also sprach Alexander Zangerl <az@bond.edu.au> [2005.06.17.0915 +0200]:
> no, this is subtly wrong. the *encrypted* block affects the decryption oft
he 
> 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 <madduck@debian.org>
: :'  :    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.

[ Post a follow-up to this message ]

also sprach Michael Buchholz <michael@bubi.dnsalias.net> [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=10000; 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 <madduck@debian.org>
: :'  :    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>

[ Post a follow-up to this message ]