linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: dsterba@suse.cz, Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	Johannes Thumshirn <jth@kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH v2 1/2] btrfs: add authentication support
Date: Tue, 5 May 2020 16:31:10 -0700	[thread overview]
Message-ID: <20200505233110.GE128280@sol.localdomain> (raw)
In-Reply-To: <20200505224611.GA18421@twin.jikos.cz>

On Wed, May 06, 2020 at 12:46:11AM +0200, David Sterba wrote:
> On Tue, May 05, 2020 at 03:31:20PM -0700, Eric Biggers wrote:
> > > Using that example, the authenticated checksum cannot be subverted on
> > > the superblock. So even if there are untrusted superblock data used, it
> > > won't even pass the verification of the superblock itself.
> > 
> > You're missing the point.  For unkeyed hashes, there's no need to provide the
> > hash algorithm name at mount time, as there's no authentication anyway.  But for
> > keyed hashes (as added by this patch) it is needed.  If the attacker gets to
> > choose the algorithms for you, you don't have a valid cryptosystem.
> 
> I think we need to be more specific as I don't see how this contradicts
> what I've said, perhaps you'll show me the exact point where I missed
> it.
> 
> An example superblock contains:
> 
> 	u8 checksum[32];
> 	int hash_type;
> 	u8 the_rest[256];
> 
> The checksum is calculated from offsetof(hash_type) to the end of the
> structure. Then it is stored to the checksum array, and whole block is
> stored on disk.
> 
> Valid superblock created by user contains may look like:
> 
> 	.checksum = 0x123456
> 	.hash_type = 0x1	/* hmac(sha256) */
> 	.the_rest = ...;
> 
> Without a valid key, none of the hash_type or the_rest can be changed
> without producing a valid checksum.
> 
> When you say 'if attacker gets to chose the algorithms' I understand it
> as change to hash_type, eg. setting it to 0x2 which would be
> hmac(blake2b).
> 
> So maybe it violates some principle of not letting the attacker choice
> happen at all, but how would the attack continue to produce a valid
> checksum?

Example: you add support for keyed hash algorithm X, and it later turns out that
X is totally broken (or was never meant to be a cryptographic hash in the first
place, but was mistakenly allowed for authentication).  You deprecate it and
tell people not to use it.  But it doesn't matter because you screwed up the
design and the attacker can still choose algorithm X anyway.

This is a basic cryptographic principle, I'm surprised this isn't obvious.

- Eric

  reply	other threads:[~2020-05-05 23:31 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 10:58 [PATCH v2 0/2] Add file-system authentication to BTRFS Johannes Thumshirn
2020-04-28 10:58 ` [PATCH v2 1/2] btrfs: add authentication support Johannes Thumshirn
2020-04-29  7:23   ` kbuild test robot
2020-04-29 11:46   ` Johannes Thumshirn
2020-05-01  5:39   ` Eric Biggers
2020-05-01  6:30     ` Eric Biggers
2020-05-04  8:38       ` Johannes Thumshirn
2020-05-05 22:33         ` David Sterba
2020-05-06  8:10           ` Johannes Thumshirn
2020-05-04 10:09     ` Johannes Thumshirn
2020-05-04 20:59       ` Eric Biggers
2020-05-05  8:11         ` Johannes Thumshirn
2020-05-05  9:26           ` Qu Wenruo
2020-05-05  9:59             ` Qu Wenruo
2020-05-05 22:32               ` David Sterba
2020-05-05 23:55                 ` Qu Wenruo
2020-05-06 20:40             ` btree [was Re: [PATCH v2 1/2] btrfs: add authentication support] Goffredo Baroncelli
2020-05-06 22:57               ` Qu Wenruo
2020-05-05 22:19           ` [PATCH v2 1/2] btrfs: add authentication support David Sterba
2020-05-05 22:37           ` Eric Biggers
2020-05-06  8:30             ` Johannes Thumshirn
2020-05-05 22:14         ` David Sterba
2020-05-05 22:31           ` Eric Biggers
2020-05-05 22:46             ` David Sterba
2020-05-05 23:31               ` Eric Biggers [this message]
2020-05-06  0:29                 ` David Sterba
2020-05-06  0:44                   ` Eric Biggers
2020-05-04 21:37       ` Richard Weinberger
2020-05-05  7:46         ` Johannes Thumshirn
2020-05-05 11:56           ` Richard Weinberger
2020-05-04 21:59   ` Richard Weinberger
2020-05-05  7:55     ` Johannes Thumshirn
2020-05-05 12:36       ` Jeff Mahoney
2020-05-05 12:39         ` Qu Wenruo
2020-05-05 12:41           ` Jeff Mahoney
2020-05-05 12:48             ` Qu Wenruo
2020-05-05 23:02           ` David Sterba
2020-05-06 21:24         ` Goffredo Baroncelli
2020-05-05 23:00     ` David Sterba
2020-05-05  9:43   ` Qu Wenruo
2020-05-06 20:59     ` Goffredo Baroncelli
2020-04-28 10:58 ` [PATCH v2 2/2] btrfs: rename btrfs_parse_device_options back to btrfs_parse_early_options Johannes Thumshirn
2020-05-01  6:03 ` [PATCH v2 0/2] Add file-system authentication to BTRFS Eric Biggers
2020-05-04  8:39   ` Johannes Thumshirn
2020-05-05 23:16   ` David Sterba
2020-05-01 21:26 ` Jason A. Donenfeld
2020-05-05 23:38   ` David Sterba

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=20200505233110.GE128280@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=dsterba@suse.cz \
    --cc=jth@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=richard@nod.at \
    /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;
as well as URLs for NNTP newsgroup(s).