From: daw@mozart.cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] loop: fixing cryptoloop troubles.
Date: Tue, 12 Aug 2003 03:30:22 +0000 (UTC) [thread overview]
Message-ID: <bh9n0e$nbf$1@abraham.cs.berkeley.edu> (raw)
In-Reply-To: 1060553236.25524.49.camel@chtephan.cs.pocnet.net
Christophe Saout wrote:
>Before encryption the data to be encrypted gets xor'ed with the result
>from the previous encrypted block. The idea in cryptoloop is that not
>the result from the previous run gets used but a specially constructed
>dummy block that has the sector number (little-endian encoded) in the
>first four bytes and is null every where else. So you simply get some
>additional perturbation based on the sector number, so that zero-filled
>sectors always looked differently after encoding.
>
>When decoding this means that the sector number is xor'ed over the
>encrypted block. If, when decoding, the sector number doesn't match that
>one that was put in the iv while encoding that sector, you will get
>errors in the first four bytes, mostly one or few bits flipped.
Unrelated to the corruption issues:
Is this how cryptoloop works? The sector number is used directly as the
IV (not the encrypted sector number)? In other words, if X denotes the
first block of plaintext and S the sector number, then the first block
of ciphertext is C = E_K(X ^ S)?
If yes, I noticed a small security weakness. This usage of CBC mode can
leak a few bits of information about the plaintext data, in some cases.
For instance, consider the following example. Let X denote the first block
of plaintext at sector S, and X' the first block of plaintext at sector S'.
Suppose X' = X^1 and S' = S^1 (here "^" denotes xor, as usual). Then
C = E_K(X^S), and C' = E_K(X'^S') = E_K((X^1)^(S^1)) = E_K(X^S) = C.
This condition can be recognized in the encrypted data.
In other words, here's the attack. The attacker looks at two sectors,
number S and S', and looks at the first block of ciphertext in each sector,
call them C and C'. If C = C', then the attacker knows that
X = X' ^ S ^ S', where X and X' denote the first block of plaintext in
each sector. If plaintext were totally random, this would almost never
happen (with probability 2^-64 for a 64-bit block cipher). However,
plaintext data often isn't exactly random. There are some plausible
ways that the condition X = X' ^ S ^ S' could arise with non-negligible
probability, and if this happens, information leaks to the attacker.
Is this a problem worth fixing? You'll have to decide. Fortunately,
there is a simple fix: use the encrypted sector number as IV, not the
plaintext sector number. In other words, the IV would be E_K(S), and
thus the first block of ciphertext would be C = E_K(X ^ E_K(S)). This
fix makes the above attack go away.
next prev parent reply other threads:[~2003-08-12 3:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-10 2:36 [PATCH] loop: fixing cryptoloop troubles Fruhwirth Clemens
2003-08-10 14:10 ` Pascal Brisset
2003-08-10 14:27 ` Christophe Saout
2003-08-10 21:03 ` Fruhwirth Clemens
2003-08-10 22:07 ` Christophe Saout
2003-08-11 13:11 ` Fruhwirth Clemens
2003-08-11 16:16 ` Christophe Saout
2003-08-12 3:30 ` David Wagner [this message]
2003-08-10 15:15 ` James Morris
2003-08-10 16:08 ` Pascal Brisset
2003-08-10 16:28 ` James Morris
2003-08-10 18:01 ` Ingo Oeser
2003-08-11 8:38 ` Pascal Brisset
2003-08-11 13:31 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='bh9n0e$nbf$1@abraham.cs.berkeley.edu' \
--to=daw@mozart.cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox