From: David Wagner <daw@cs.berkeley.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Delete cryptoloop
Date: Fri, 30 Jul 2004 17:44:24 -0700 (PDT) [thread overview]
Message-ID: <200407310044.i6V0iOZe032440@taverner.CS.Berkeley.EDU> (raw)
In-Reply-To: <1091193219.11944.17.camel@leto.cs.pocnet.net> from "Christophe Saout" at Jul 30, 2004 03:13:39 PM
> 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)
[...]
Yes, there are a host of potential attacks in this scenario. That's why I
wrote that, if you find yourself in this threat model, it would be prudent
to assume that the current disk encryption scheme can potentially be
defeated. Does anyone care about these threat models? From the design,
I had assumed that no one cared, but if they are relevant in practice,
then it might make sense to investigate additional defenses.
The natural defense against these attacks would be to add a MAC, but this
has the disadvantage of increasing ciphertext lengths and thus may be
unsuitable for disk encryption. Also, a MAC might still be susceptible
to some attacks based on cutting and splicing old ciphertext sectors
with new ciphertext sectors, or somesuch. In other words, a vanilla MAC
does not ensure freshness (it doesn't stop replaying old ciphertexts),
unless it is augmented with additional mechanisms. It is not clear to
me whether this would matter in practice.
An alternative possibility would be to use a tweakable block cipher.
The block width would be the size of the sector, and the sector number
would be used as the tweak. This doesn't prevent the attacker from
fooling around with ciphertexts; it just ensures that if the attacker
changes what is on disk to some new value, then its decryption will be
randomized and unpredictable to the attacker. One would have to spend
a little time thinking about whether this is good enough in practice.
Note that a tweakable block cipher retains the potential for replaying
old ciphertexts just like a MAC would.
Also, I haven't said anything about traffic analysis threats. If the
attacker can observe the encrypted data on your hard disk at multiple
times, he may be able to identify some partial information about which
sectors or blocks of data have changed at which times. There may be
some things one could do about this, if it matters to anyone.
next prev parent reply other threads:[~2004-07-31 0:44 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
2004-07-31 0:44 ` David Wagner [this message]
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=200407310044.i6V0iOZe032440@taverner.CS.Berkeley.EDU \
--to=daw@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
all inboxes | Powered by JetHome®