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
--
On Fri, Jun 17, 2005 at 10:47:49PM +0200, Marcin Owsiany wrote:
> On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote:
> > Does anyone know what generated the above log entries?
>
> try:
>
> find /usr/sbin /sbin /usr/local/sbin \
> /usr/bin /usr/local/bin /bin /usr/lib /lib -type f
On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote:
> Does anyone know what generated the above log entries?
try:
find /usr/sbin /sbin /usr/local/sbin \
/usr/bin /usr/local/bin /bin /usr/lib /lib -type f | \
while read f; do
if strings $f | egrep -q 'no ip\?!'; then
echo "it's
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
Hi,
Logcheck has just given me three of the following:
Jun 17 17:17:15 hexstream [877]: root login denied [username: (0), IP/port: no
ip?!]
Each one with a different PID. They appear in my /var/log/auth.log
I've never seen this type of message before but I've recently upgraded to the
latest
re
> "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
Greetings,
Am Freitag, 17. Juni 2005 10:58 schrieb Florian Weimer:
> Rumors suggest that the technical foundations of security support for
> sarge and woody are working again.
Nice to hear - however, a SpamAssassin-patch has to be ported to sarge.[1]
Let's see... the Sec-Announce was posted ~2 d
Hi there!
Since the end of april there is known an security issue for Spamassassin,
which is described here[0]
This issue has been assigned CVE id CAN-2005-1266 [1].
The question which comes in my mind ... how (and when) will this be fixed in
sarge, when the security infrastructure is broken.
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
Rumors suggest that the technical foundations of security support for
sarge and woody are working again.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
27 matches
Mail list logo
