Hi,
First a description of my machine:
I use a Dual Celeron System with glibc-2.1.3 and
linux-2.4test10 .
For information on peripherial devices I give the output of /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bri
> Ingo, do you have a BP6? Make sure you have the latest BIOS for your
> motherboard, there have been many BIOS updates for some dual-Celeron
> motherboards.
I have to admit that I'm not sure what kind of dual board I got
(i have to have a closer look).
The reason is that this board is orgiginal
Hi,
I found a way to crash an SMP 2.4-test11 kernel:
1. Create a BIG file (lets say about 300-400 MByte)
2. use losetup and the loop device to create an
ext2 filesystem within the file
3. mount the file
4. copy huge amounts of data into the file.
(for example copy your /usr directory into
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are in
Hi again,
Marc Mutz wrote:
> > The loop device supports different IVs;
> > the IVs are initilized with the requested block
> > number.
> > I believe a better way is to use the requested
> > sector number from CURRENT->sector.
> > Using this value should make the encryption and decryption
> > pr
Ian Sterling wrote:
> But, it seems to me that being able to have a different IV for
> each filesystem would be a good thing, but having it depend on something
> as volatile as sector of the disk, seems bad.
It's not the sector of the _disk_. It's the requested sector
of the loop device. The r
> _I_ can use my approach, but not yours, to bring my already existing
> crypted fs into the new state. The losetup option to set the encryption
> chunk size is used only once for each fs, but at that one time you can
> do:
Ok, I understand what you mean.
> Q> losetup -e blowfish --use-fs-blocks
> BTW, kerneli would also not handle the case of switching block sizes anyways,
> with relative IVs or not, because it does not restart its CFB chain inside
> the device blocks every 512 byte blocks with a new IV.
My (inofficial) patch set for twofish and blowfish does though :-).
I'm not sure if
> So, the only provision that needs to be made to ensure backwards
> compatibility (both with the kerneli patch and other modules that still
> use absolute block numbers) is a way to switch between the new approach
> and the old, defaulting to the new. The easiest way to do this, IMO, is
> to allo
Reed Petty wrote:
> Caution is advised when depending upon crypto systems that use relative
> block numbers as IV. The security may not be a strong as hoped.
> There are some who believe that "not unique" IVs (across multiple
> filesystems) facilitates some methods of cryptanalysis.
...
Ahh
>
> > > IV generation is what I am worried about.
> > > There is a paper about why it is a bad idea to use
> > > sequence numbers for CBC IV's. I just have to find the reference to it.
> > Does this mean sequence as in 0,1,2,3,4 ... or does this mean
> > any pre-calculate-able sequence ? In the f
Hi
Please have a look at
http://www.in.tum.de/~rohloff
I put two implementations of twofish on the site
and also a modified loop.c
(which uses requested sector number as IV and
fixes another problem with xfer->lock and unlock.)
The first implementation of twofish basically
uses an IV seed whi
ix.c). Then again probably not ...
so long
Ingo Rohloff
PS: Burning a CD was only one trigger for the problem. In fact
accessing my CDBurner in any way (like mounting a CD, or reading
from it) will lock up my whole computer, as long as
"hdparm -d1 -X34" isn't called
Hi,
There is a bug in the locking scheme for the encryption functions,
which can be hooked into the loop device. I have a patch
which resolves the problem. First what happens:
If you do (for example) a losetup -e twofish /dev/loop0 test.lop
the following happens:
The loop0 device gets opened (t
> > Locking twice? But what happens if some program calls loop_set_status more
> > than once? Losetup doesn't, but if such program exists, locking is still
> > screwed.
>
> No, it calls loop_release_xfer always before init_xfer, which will release
> the "permanent" use count.
Calling lock twice i
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 8a94c1ab34d53476617f83610521cfb6674db8d4
Gitweb:
https://git.kernel.org/tip/8a94c1ab34d53476617f83610521cfb6674db8d4
Author:Ingo Rohloff
AuthorDate:Wed, 22 Apr 2020 13:28:57 +02:00
Committer
16 matches
Mail list logo