On Mon, Oct 16, 2000 at 06:23:32PM +, David Wagner wrote:
(snip)
>
> Using SHA1(sector #) should be ok, as long as you don't expect your
> plaintexts to have similar patterns. (If you do think your plaintexts
> might begin with the SHA1-hashes of sector numbers, you could use a
> "keyed
Ingo Rohloff wrote:
>-snip---
> As an example, it is not true that CBC encryption
> can use an arbitrary nonce initialization vector: it is essential
> that the IV be unpredictable by the adversary. (To see this, suppose
>
Ingo Rohloff wrote:
>> 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 former case we might just use
>a simple
>
> > > 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
David Wagner wrote:
>
> Marc Mutz wrote:
> >> There are some who believe that "not unique" IVs (across multiple
> >> filesystems) facilitates some methods of cryptanalysis.
> >
> >Do you have a paper reference?
>
> (However, it does get one
> thing wrong: it claims that it's ok to use a
Ingo Rohloff wrote:
>
> > I can convert the stuff _in place_ (it actually works, anyone please
> > complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax
> > and I don't have sizeof(/dev/hdax) space left on my hard drives.
> This could be dangerous. I'm not sure that the kernel
Ingo Rohloff wrote:
snip
I can convert the stuff _in place_ (it actually works, anyone please
complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax
and I don't have sizeof(/dev/hdax) space left on my hard drives.
This could be dangerous. I'm not sure that the kernel
Ingo Rohloff wrote:
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 former case we might just use
a simple one way
Ingo Rohloff wrote:
-snip---
As an example, it is not true that CBC encryption
can use an arbitrary nonce initialization vector: it is essential
that the IV be unpredictable by the adversary. (To see this, suppose
the
On Mon, Oct 16, 2000 at 06:23:32PM +, David Wagner wrote:
(snip)
Using SHA1(sector #) should be ok, as long as you don't expect your
plaintexts to have similar patterns. (If you do think your plaintexts
might begin with the SHA1-hashes of sector numbers, you could use a
"keyed hash",
Marc Mutz wrote:
>> There are some who believe that "not unique" IVs (across multiple
>> filesystems) facilitates some methods of cryptanalysis.
>
>Do you have a paper reference?
There's no paper, because it's too trivial to appear in a paper.
But you can find this weakness described in any
kernel wrote:
>There are some who believe that "not unique" IVs (across multiple
>filesystems) facilitates some methods of cryptanalysis.
It's a not a matter of "belief"; it's a matter of fact.
The weakness is that the first block of ciphertext depends
only on the IV and the first block of
IV's should never be repeated (per key). If you are using CBC mode,
they should not be just a counter, either (for different reasons).
A simple implementation technique is simply to use the encryption of
a block number / sector number / counter as your IV. This ensures that
IV's don't repeat
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
> 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
> 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
> _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
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
Andi Kleen wrote:
>
> On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote:
> > This thread was about encryption. And it was about IV's. The only
> > encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'.
> > None is just that: a no-op. And xor does not use an IV. So the
Andi Kleen wrote:
On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote:
snip
This thread was about encryption. And it was about IV's. The only
encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'.
None is just that: a no-op. And xor does not use an IV. So the only
_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-blocksize \
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 allocate
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
On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote:
> Andi Kleen wrote:
> >
> > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
> > > Andi Kleen wrote:
> > > >
> > >
> > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > > from disk absolute to
Andi Kleen wrote:
>
> On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
> > Andi Kleen wrote:
> > >
> >
> > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > from disk absolute to relative). When you change it now (before 2.4.0)
> > > it is relatively painless.
kernel 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.
>
Do you
On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote:
(snip)
> 2.4 has already broken backwards compatibility to 2.2 (IV changed
> from disk absolute to relative). When you change it now (before 2.4.0)
> it is relatively painless. I think the change is a good idea.
>
Caution is advised
On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
> Andi Kleen wrote:
> >
>
> > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > from disk absolute to relative). When you change it now (before 2.4.0)
> > it is relatively painless. I think the change is a good
Andi Kleen wrote:
>
> 2.4 has already broken backwards compatibility to 2.2 (IV changed
> from disk absolute to relative). When you change it now (before 2.4.0)
> it is relatively painless. I think the change is a good idea.
You're wrong. All kernels from int-2.2.10.4 onwards can be
Ingo Rohloff wrote:
>
> > First: This breaks backward-compatibility.
> Right, (I mentioned this), but the backward-compatible
> way means:
>
Don't confuse the backwards-compatible way with the current (broken, of
course) way of doing things. It is right that the _current_ approach of
using
Andi Kleen wrote:
snip
2.4 has already broken backwards compatibility to 2.2 (IV changed
from disk absolute to relative). When you change it now (before 2.4.0)
it is relatively painless. I think the change is a good idea.
snip
You're wrong. All kernels from int-2.2.10.4 onwards can be
On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote:
(snip)
2.4 has already broken backwards compatibility to 2.2 (IV changed
from disk absolute to relative). When you change it now (before 2.4.0)
it is relatively painless. I think the change is a good idea.
Caution is advised when
Andi Kleen wrote:
On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote:
Andi Kleen wrote:
snip
2.4 has already broken backwards compatibility to 2.2 (IV changed
from disk absolute to relative). When you change it now (before 2.4.0)
it is relatively painless. I think the
On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote:
> >
> > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
>
> > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > from disk absolute to relative). When you change it now (before 2.4.0)
> > it is
>
> On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
> 2.4 has already broken backwards compatibility to 2.2 (IV changed
> from disk absolute to relative). When you change it now (before 2.4.0)
> it is relatively painless. I think the change is a good idea.
I've been away from
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
> 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
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
> >
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
process
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
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.
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
snip
2.4 has already broken backwards compatibility to 2.2 (IV changed
from disk absolute to relative). When you change it now (before 2.4.0)
it is relatively painless. I think the change is a good idea.
I've been away from
On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote:
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote:
snip
2.4 has already broken backwards compatibility to 2.2 (IV changed
from disk absolute to relative). When you change it now (before 2.4.0)
it is relatively
[added cc: linux-crypto]
Ingo Rohloff wrote:
>
> 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
[added cc: linux-crypto]
Ingo Rohloff wrote:
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.
44 matches
Mail list logo
