mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christophe Saout <christophe@saout.de>
To: David Wagner <daw@cs.berkeley.edu>
Cc: James Morris <jmorris@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Delete cryptoloop
Date: Fri, 30 Jul 2004 15:13:39 +0200	[thread overview]
Message-ID: <1091193219.11944.17.camel@leto.cs.pocnet.net> (raw)
In-Reply-To: <200407292115.i6TLFTpo017213@taverner.CS.Berkeley.EDU>

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Am Donnerstag, den 29.07.2004, 14:15 -0700 schrieb David Wagner:

> > IV = sector number (little endian, 32 bits), pad with zeroes
> > The actual content is then encoded using the selected cipher and key in
> > CBC mode.
> > C[0] = E(IV     xor P[0])
> > C[1] = E(C[0]   xor P[1])
> > ...
> 
> Ok, that's what I thought.  The above is pretty good, but does have some
> weaknesses due to the IV selection.  CBC mode needs uniformly random IVs
> for security; using a counter can cause occasional information leakage.

Yes, we already identified this problem.

> You can see that the information leakage is typically modest and limited;
> in many cases, there might be no leakage at all.  Nonetheless, this is
> not an ideal situation.  As a cryptographer, one would usually consider
> this a flawed design (primarily because it is so easy to do better).
> There are known ways to prevent this attack; for instance, IV = E(sector
> number) or IV = HMAC(sector number) should be much better.

Exactly.

But we identified more problems (I don't if these are all real issues).

Assuming the attacker has access to both plaintext and the encrypted
disk. (shared storage, user account on the machine or something)

A simple one is if you set a sector to all zeroes, due to CBC you get
tons of plaintext-encrypted pairs on the encrypted disk.

One problem would be that if he modifies a sector only the rest of that
sector changes, starting from the block he changed.
Since CBC uses C[n] = E(C[n-1] xor P[n]) he could set P[n] = C[n-1] and
then has C[n] = E(0) which could be precomputed.

This can't happen if the IV also depends on the sector content, like IV
= HMAC(sector number, P[1 .. n-1])

Or if the attacker can copy around sectors on the encrypted side (shared
storage) from one location to another location where he has read access
on the machine that can decrypt the data, he can simply read the data
except for the first block (if secured by an "random" IV). This can't be
avoided when using CBC and a single key for every sector.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-07-30 13:13 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-21 20:16 James Morris
2004-07-21 23:44 ` David S. Miller
2004-07-22  6:00 ` Andrew Morton
2004-07-22  3:30   ` James Morris
2004-07-22  7:43     ` Matthias Urlichs
2004-07-22 14:14       ` H. Peter Anvin
2004-07-22 14:58         ` Jack Lloyd
2004-07-28 20:24     ` David Wagner
2004-07-29  0:27       ` James Morris
2004-07-29 15:50         ` Christophe Saout
2004-07-29 21:15           ` David Wagner
2004-07-30 13:13             ` Christophe Saout [this message]
2004-07-31  0:44               ` David Wagner
2004-07-31  2:05                 ` Matt Mackall
2004-07-31 17:29                   ` Marc Ballarin
2004-08-02 22:54                   ` David Wagner
2004-08-02 23:16                     ` James Morris
2004-08-07 16:27                       ` Jean-Luc Cooke
2004-07-22  4:26   ` dpf-lkml
2004-07-22  5:22     ` James Morris
2004-07-22 11:58       ` Paul Rolland
2004-07-22 20:40         ` Martin Schlemmer
2004-07-22  8:46     ` Andrew Morton
2004-07-22  6:13       ` Dale Fountain
2004-07-22  6:47         ` Tim Connors
2004-07-22 15:02           ` Petr Baudis
2004-07-22 11:36         ` Aiko Barz
2004-07-24 15:11           ` Andreas Jellinghaus
2004-07-24 15:53       ` gadgeteer
2004-07-29 16:12       ` Andries Brouwer
2004-07-29 17:23         ` James Morris
2004-07-29 19:48           ` Andries Brouwer
2004-07-22 22:13 ` Bill Davidsen
2004-07-24 12:41 ` Fruhwirth Clemens
2004-07-24 16:52   ` Andrew Morton
2004-07-24 14:08     ` Andreas Henriksson
2004-07-24 19:54       ` Paul Jackson
2004-07-27 20:02     ` Bill Davidsen
2004-07-25 11:42   ` Jari Ruusu
2004-07-25 13:24     ` Fruhwirth Clemens
2004-07-25 15:24       ` Marc Ballarin
2004-07-25 16:57       ` Andreas Jellinghaus
2004-07-25 17:25       ` Jari Ruusu
2004-07-25 18:02         ` Fruhwirth Clemens
2004-07-25 19:09           ` Lee Revell
2004-07-25 19:15             ` Fruhwirth Clemens
2004-07-25 19:44           ` Marc Ballarin
2004-07-25 20:58             ` Fruhwirth Clemens
2004-07-26 10:54           ` Jari Ruusu
2004-07-26 12:45             ` Fruhwirth Clemens
2004-07-26 18:11               ` Jari Ruusu
2004-07-26 22:59                 ` Fruhwirth Clemens
2004-07-26 20:01               ` Matt Mackall
     [not found]                 ` <fa.edslbgp.q763qd@ifi.uio.no>
2004-07-27  8:40                   ` Junio C Hamano
2004-07-27  8:53                     ` Matt Mackall
2004-07-27 10:10                     ` Marc Ballarin
2004-07-26 22:04               ` Marc Ballarin
2004-07-27 19:56   ` Bill Davidsen
     [not found] <2kMAw-rl-15@gated-at.bofh.it>
2004-07-22 19:44 ` Pascal Brisset
2004-07-23 10:59 Thomas Habets
     [not found] <2kvT4-5AY-1@gated-at.bofh.it>
     [not found] ` <2kC85-1AH-11@gated-at.bofh.it>
     [not found]   ` <2kDxa-2sB-1@gated-at.bofh.it>
     [not found]     ` <2kECW-3a0-7@gated-at.bofh.it>
2004-07-23 12:34       ` Walter Hofmann
2004-07-23 14:01         ` Kevin Corry
2004-07-23 18:20           ` Christophe Saout
2004-07-27 19:47         ` Bill Davidsen
2004-07-23 12:50 mattia
2004-07-26  7:13 Adam J. Richter
2004-07-30  8:43 Markku-Juhani O. Saarinen

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=1091193219.11944.17.camel@leto.cs.pocnet.net \
    --to=christophe@saout.de \
    --cc=daw@cs.berkeley.edu \
    --cc=jmorris@redhat.com \
    --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

all inboxes | Powered by JetHome®