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 cas
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
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
--
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),
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?
>
>
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.
--
P
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
--
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 block
> "martin" == martin f krafft <[EMAIL PROTECTED]> writes:
>> And also, when you write any block, you have to reencrypt all
>> the remaining blocks.
martin> Yes, don't you?
Didn't you realize that if that is the case, every single-byte write
would means writing, on average, half t
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 li
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 contai
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 so
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
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 erro
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
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
-
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), t
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
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
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) encr
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
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 a
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
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 followin
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 cip
* 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_firs
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
enoug
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 b
* 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. 6
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
* 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
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
32 matches
Mail list logo
