All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Dmitry Monakhov <dmonlist@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	mhalcrow@google.com, Ildar Muslukhov <muslukhovi@gmail.com>
Subject: Re: [PATCH-v2 08/20] ext4 crypto: add encryption key management facilities
Date: Wed, 27 May 2015 14:37:24 -0400	[thread overview]
Message-ID: <20150527183724.GA18540@thunk.org> (raw)
In-Reply-To: <20150527170606.GA31840@thunk.org>

On Wed, May 27, 2015 at 01:06:06PM -0400, Theodore Ts'o wrote:
> 
> That's not true.  If the attacker finds the encryption key for an
> inode, and they have the nonce which is stored in file's extended
> attribute, what the attacker has is a single plaintext/ciphertext
> pair.  That doesn't imply that they can get the master key; they would
> still need to do a brute force search on the keyspace try to find the
> master key.

So an update, after conferring with Michael Halcrow, who set me
straight.  I was wrong, because I mixed up which was the deriving key
and which was the source key.  You're correct; if an attacker could
get ahold of the per-file key, they could use the nonce to decrypt it
and obtain the master key.

However, there are only two ways to determine the per-file key.  The
first is a ring 0 compromise, in which case it's likely they could get
access to the master key, and the second is if there is a practical
known-plaintext attack on AES, and the attacker has access to the
block device --- and possibly a chosen-plaintext attack if the
attacker can control what data is written to the file.  But either
way, if there is such a crypto-analytic attack on AES, then this is
going to be least of the whole world's problems.  :-)

There are alternatives, such as either using the master to encrypt the
nonce and none+1: (AES-256-ENCRYPT(nonce) || AES-256-ENCRYPT
(nonce+1)).  But this will be 40% slower than what we are currently
doing, which is to use AES-256 to encrypt the master key.

Or we could use an HMAC, which would be even slower yet, especially
since many chips have AES acceleration, but few have SHA hardware
acceleration.

So ultimately, the question is whether we want to make a change (with
all of the versioning work we would need for backwards compatibility)
that decreases performance, which will be especially noticeable for
small files, to protect against a partial Ring 0 compromise when other
Ring 0 compromise would make us be toast anyway.

						- Ted

  reply	other threads:[~2015-05-27 18:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13  3:16 [PATCH-v2 00/20] ext4 encryption patches Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 01/20] ext4 crypto: add ext4_mpage_readpages() Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 02/20] ext4 crypto: reserve codepoints used by the ext4 encryption feature Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 03/20] ext4 crypto: add ext4 encryption Kconfig Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 04/20] ext4 crypto: export ext4_empty_dir() Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 05/20] ext4 crypto: add encryption xattr support Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 06/20] ext4 crypto: add encryption policy and password salt support Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 07/20] ext4 crypto: add ext4 encryption facilities Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 08/20] ext4 crypto: add encryption key management facilities Theodore Ts'o
2015-05-27 13:39   ` Dmitry Monakhov
2015-05-27 17:06     ` Theodore Ts'o
2015-05-27 18:37       ` Theodore Ts'o [this message]
2015-05-29 17:55         ` Dmitry Monakhov
2015-05-29 18:12           ` Dmitry Monakhov
2015-05-29 20:03           ` Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 09/20] ext4 crypto: validate context consistency on lookup Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 10/20] ext4 crypto: inherit encryption policies on inode and directory create Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 11/20] ext4 crypto: implement the ext4 encryption write path Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 12/20] ext4 crypto: implement the ext4 decryption read path Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 13/20] ext4 crypto: filename encryption facilities Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 14/20] ext4 crypto: teach ext4_htree_store_dirent() to store decrypted filenames Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 15/20] ext4 crypto: insert encrypted filenames into a leaf directory block Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 16/20] ext4 crypto: partial update to namei.c for fname crypto Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 17/20] ext4 crypto: filename encryption modifications Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 18/20] ext4 crypto: enable filename encryption Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 19/20] ext4 crypto: Add symlink encryption Theodore Ts'o
2015-04-13  3:16 ` [PATCH-v2 20/20] ext4 crypto: enable encryption feature flag Theodore Ts'o

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=20150527183724.GA18540@thunk.org \
    --to=tytso@mit.edu \
    --cc=dmonlist@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=muslukhovi@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.