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
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
Marc Mutz wrote:
>David Wagner wrote:
>> (However, it does get one
>> thing wrong: it claims that it's ok to use a serial number for your
>> IV. This is not correct, and I can give a reference for this latter,
>> subtler point, if you like.)
>>
>Yes, please.
One reference is
http://www.cs.ucda
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
> t
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 f
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 serial
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 h
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 good
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 plai
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 an
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 allo
> 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
> _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
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
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 o
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 relative
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. I
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 w
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 idea.
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 configure
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 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 relati
>
> 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 th
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 CURR
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
[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
29 matches
Mail list logo
