Re: cryptoloop CBC mode
From: Kasper Dupont (kasperd@daimi.au.dk)Date: 02/21/02
- Next message: RainbowHat: "Re: xtreelic !"
- Previous message: burning chrome: "Re: BestCrypt?"
- In reply to: Nick Battle: "Re: cryptoloop CBC mode"
- Next in thread: Kasper Dupont: "Re: cryptoloop CBC mode"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Kasper Dupont <kasperd@daimi.au.dk> Date: Thu, 21 Feb 2002 10:49:44 +0100
Nick Battle wrote:
>
> Kasper Dupont wrote:
> > BUT if there are some similar blocks that are not completely
> > identical it could be the case that two would get same encryption.
> > With access to the encrypted version you could look for diskblocks
> > where the first 16 bytes (one cipher block) of the encryption are
> > identical. For such blocks you will know exactly which bits differ
> > between the unencrypted versions of the blocks.
>
> This would have to be between two devices, encrypted under the same key,
> with block-number-overlap. Yes, then I agree.
First of all the IV is the offset in the backingfile that is
the offset on the virtual device. So I don't understand why
you say with block-number-overlap, cause that will always be
the case. (There are some broken kernels where the IV has
other values, but that makes all backups of the backingfile
useless.)
>
> > If I write all zero bytes to an encrypted loopback device all blocks
> > will be encrypted differently. But if I then write a one byte in the
> > first byte of the device the first two blocks will have identical
> > encryptions, which is not good.
>
> I don't understand this. Presumably you've tried it? I don't see why the
> different IVs for the two blocks don't scramble the cipherblocks to be
> totally different.
Yes, I tried it. The problem is that the two blocks are
different, and the two IVs are different. But after applying
the IVs the two blocks will be identical and will thus result
in same encryption.
>
> > Encrypting the block number and using that as IV will solve this
> > problem, and I don't see any new vulnerability introduced by doing
> > this.
>
> I'm sorry Kasper, I must still have missed something. Encrypting a known
> IV under a fixed key will just result in a fixed (albeit wierd loooking)
> IV.
Exactly. The IVs must be fixed because we need an algorithm
to reproduce them when decrypting blocks. The "weird looking"
IVs will no longer be predictable, thus reduces the risk of
two blocks being identical after applying the IVs. At the
same time this also reduces the value of such collisions for
an advesaray, because he don't know the differences between
the IVs.
> The IVs for block #123 on two devices, using the same key, will
> still be the same. Isn't the vulnerability you describe because the
> IV/key combination is the same for two pieces of data, and so if the
> plaintext is identical that is apparent in the ciphertext? In which
> case, if the IV/key is the same for two blocks, encypting the IV under
> the key will still be the same (ok, different cipher output, but the
> same result for the two blocks, so still vulnerable).
I'm not talking about two devices encrypted under same key.
I agree that that would be a bad idea in any case (unless
the one is actually a backup of the other). I'm talking
about a single device encrypted under one key.
>
> > Different passwords for different devices sounds reasonable. And
> > the IV will help on identical blocks on the same device. But the IV
> > will be no good for two blocks where the blocks differ in the same
> > bits as the block numbers.
>
> I think this depends on the cipher used and how the IV interacts with
> the production of the ciphertext. I thought it was in the nature of good
> cipher design that any difference on the input (ie. a single bit changed
> in the IV or the plaintext) changes roughly 50% of the output bits at
> random - ie. a single bit difference, anywhere, produces a "totally
> random" change in the output. So as long as the IVs are even a little
> bit different (like sequential numbers), you're OK. There should be no
> relationship with the corresponding bits of the plaintext.
It doesn't depend on the cipher. I'm not talking about
problems in the cipher, i'm talking about a problem in the
mode. The IV is xored to the data, if that results in the
same input to the cipher no cipher will help. All ciphers
will produce same output given the same input. So changing
the cipher will not help, but changing the IV to something
random will help, in this case the random value could be
the encryption of the IV.
>
> Unless we're talking XOR here or something... :^)
When applying the IV to the block XOR is always used. But
of course the cipher is not XOR. (Didn't I actually say
that I was using aes?)
>
> One of us is very confused (and I think it might be me!)
Hopefully we can clearify this.
>
> Cheers,
> -nick
-- Kasper Dupont For sending spam use mailto:razor-report@daimi.au.dk
- Next message: RainbowHat: "Re: xtreelic !"
- Previous message: burning chrome: "Re: BestCrypt?"
- In reply to: Nick Battle: "Re: cryptoloop CBC mode"
- Next in thread: Kasper Dupont: "Re: cryptoloop CBC mode"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
