From owner-freebsd-hackers@freebsd.org Fri Nov 6 23:53:55 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A456D2D7399 for ; Fri, 6 Nov 2020 23:53:55 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CScfp3hJyz3FH1 for ; Fri, 6 Nov 2020 23:53:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 0A6NrqIa030546 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 15:53:52 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0A6Nrqq4030545; Fri, 6 Nov 2020 15:53:52 -0800 (PST) (envelope-from jmg) Date: Fri, 6 Nov 2020 15:53:52 -0800 From: John-Mark Gurney To: Eric McCorkle Cc: FreeBSD Hackers Subject: Re: Mounting encrypted ZFS datasets/GELI for users? Message-ID: <20201106235352.GE31099@funkthat.com> Mail-Followup-To: Eric McCorkle , FreeBSD Hackers References: <8d467e98-237f-c6a2-72de-94c0195ec964@metricspace.net> <20201026221215.GB31099@funkthat.com> <794d789d-4056-4152-e7f6-bf9d10d42518@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <794d789d-4056-4152-e7f6-bf9d10d42518@metricspace.net> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 06 Nov 2020 15:53:52 -0800 (PST) X-Rspamd-Queue-Id: 4CScfp3hJyz3FH1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.20 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 23:53:55 -0000 Eric McCorkle wrote this message on Sat, Oct 31, 2020 at 15:48 -0400: > On 10/26/20 6:12 PM, John-Mark Gurney wrote: > > Eric McCorkle wrote this message on Mon, Oct 05, 2020 at 09:45 -0400: > >> I'm presently looking into options presented by ZFS encryption. One > >> idea I had was something like this (I'm going to go with ZFS for now, > >> but you could presumably do something like this with GELI, with more > >> effort). > > > > I'd still recommend using GELI. Even w/ ZFS's native encryption, the > > metadata for ZFS remains unencrypted, and able to be munged. If you > > geli w/ ZFS and a strong checksum, like sha512/256, I believe that this > > is the equiavlent to authenticated encryption, ala geli's authenticated > > mode, but with significantly less overhead... > > Something to note is that GELI's authenticated mode changes the block > size, because it uses the last bytes in each block to hold the MAC. > This is likely to have consequences for performance. Which is why I don't use it, and use GELI's unauthenticated mode (default) w/ ZFS strong hashes... > However, this also does suggest a ZFS feature that would create a MAC > code for the root block of the filesystem (I am less familiar with the > ZFS on-disk format, but as it's a write-once format with MAC information > stored at each block pointer, this would have the effect of protecting > the entire filesystem from offline tampering. Yes, that is one of the reasons I'm not interested in ZFS native encryption is that it only protects datasets, but the rest of the metadata is not protected... Adding MACs all of the ZFS metadata blocks would be good for native ZFS encryption, but short of encrypting ALL the ZFS metadata, it doesn't satisfy my needs... The reason I'm fine w/ GELI + sha512/256 is the way AES blocks work.. GELI w/ AES-XTS, each 16byte chunk is encrypted w/ a stream cipher, so there is zero overlap between chunks. W/ sha512/256, the hash is 32bytes. So, an attacker would have to corrupt TWO 16 byte blocks of data wich exactly the correct data, to get ZFS to trust the checksum. If an attacker can do that, they very likely have the encryption key, so it's game over anyways. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."