From nobody Wed Aug 23 07:38:32 2023 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RVyks3TVKz4rFWf for ; Wed, 23 Aug 2023 07:38:45 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RVyks13KKz4bFf for ; Wed, 23 Aug 2023 07:38:44 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-52a1132b685so3340965a12.1 for ; Wed, 23 Aug 2023 00:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ofwilsoncreek-com.20221208.gappssmtp.com; s=20221208; t=1692776323; x=1693381123; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=du0bltYC0MR0ad+1sZjYNLkKRzqAcTJVRJVzUEoyn9U=; b=W9AmHf78v2Z9AuC054ViMNRPzoTHV6MOheFJHBEV6Jkn92ZVjXRo/9cH5AYB2pHdG8 Tuzum16+Fq8o0ZT38Gk9J9fHlnqgdIRAzO36iWRo7wsBjYCKnX4VNAPDmPVqoNYplA6N qYdw5vWswX/US4bJkzkkWuWXaxDK2tEsPLcOjPkn1LhctUVbhJoWzYci2vhBT2hS4jrF 3yuTFddFaXGaGtpRBNofugvfVVNkaR2vN0udTrHc9btfJGWXHgn3oZ3QRpRItdakvJbV rhWLevqsjk+MkvdZ3Lwc+SHRueYYlNOzibHVvHJnqrRjWnWYKhPSlJW4jh4nlGGpySDw Hf7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692776323; x=1693381123; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=du0bltYC0MR0ad+1sZjYNLkKRzqAcTJVRJVzUEoyn9U=; b=TB7IN1EMV8LJTvdaH+GjSb5GytAM7tDyNQ1U6ShAEE0QZKDRXNgMKw5WjlbFVy1ibJ lJ8RVOL87ZF0bnqfzef1SE0VLG+TVuqB1nf4nDkLSBRqLPEuV+HE78PlDToJp+uVcpk8 70dzY6dN5yB8dKGR0yKFwH/rG167Qlib+XRql9ToOpYISD80WmWBNJIfjF+ruEYWU37B 6bg3vEp+2+lh/Zl3gkaqdTIyBbmB84P1lry6d7hUEmzQx6n5Wv/ZBZ40pJEhZHFbA/Du cEKS3hJ9Xc0Efl9FnVzTzTrA290MoQ9qB7441QDnRn9LA3P+yYzCGveD4zA7cRIkcNsM gv/A== X-Gm-Message-State: AOJu0Yzpd6gASN1mixkHCXGu1cDZoX3/jORCe4KqtVLbh6ltPhdEe7tZ qmcsfYyFhe/DJACNYGa9LHS7d63bhlqTB/pBYxrKNfMnbwkgMs/6 X-Google-Smtp-Source: AGHT+IEVfhe7GJr6imcnhsfOIVmjWcdQFcSBHGGrfzml+p1um9YWi5Ui6L9r0R1YrJIIGMerHWtzCSdGPu9XxJntURs= X-Received: by 2002:aa7:d34f:0:b0:525:4f15:d26e with SMTP id m15-20020aa7d34f000000b005254f15d26emr8049469edr.32.1692776323347; Wed, 23 Aug 2023 00:38:43 -0700 (PDT) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Leif Pedersen Date: Wed, 23 Aug 2023 02:38:32 -0500 Message-ID: Subject: Re: Is ZFS native encryption safe to use? To: grarpamp Cc: freebsd-questions@freebsd.org, freebsd-security@freebsd.org Content-Type: multipart/alternative; boundary="000000000000700b2806039233f5" X-Rspamd-Queue-Id: 4RVyks13KKz4bFf X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000700b2806039233f5 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 23, 2023, 02:02 grarpamp wrote: > On 8/22/23, iio7@tutanota.com wrote: > > There seems to be a bit of open (and rather old) ZFS native encryption > > bugs which still haven't been fixed and it doesn't look like it is > > something that is being working on. > > > > Last night I was going to move some important files from an unencrypted > > dataset to a new encrypted (ZFS native) one, but then got my doubts > > about doing that (looking at all the different open GitHub issues on > > OpenZFS). > > > > There exist some rumors about the original company which did the ZFS > > native encryption work (the person doing the work left the company), > > and they haven't done more since. > > > > What is the general experience running with ZFS native encryption on > > FreeBSD? Is it better to use GELI for the whole pool instead? > > Neither GELI, nor the rest of the crypto subsystem, > nor the kernel, nor userland... has ever undergone > anything close to a real security audit, let alone an > independent one, let alone been formally verified. > > And agents, moles, malactors, bugs, and worse are running > rampant across the entire computing spectrum... from fab, > to shipping, to OS and crypto development, to magic packets, > to telecom, to phones, to firmware, software, apps, and updates, > BGP, your ISP, frontdoor, backdoor, back orifice, and more. > > Your use of any crypto, on any operating system, on any > hardware platform, on any network, is entirely at your own risk. > > Still lots of fun yet to be had... > > #OpenFabs , #OpenHW , #OpenAudit , #FormalVerification , > #CryptoCrowdFunding , #OpenTrust , #GuerrillaNets , > #P2PFiber , #GNURadioRF , #PrivacyCoins , #DropGangs , ... > Maybe it would work to use both. Encrypt the underlying devices with geli, plus encrypt the zfs dataset. I haven't tried this but it logically should be easy to layer them. You would be protected against a bug affecting either one this way, but of course the risk of both being compromised is still nonzero. For the best protection, perhaps different ciphers could be used. I'm not sure what options there are but I'm curious if someone in this wheelhouse could fill in my gaps. - Leif --000000000000700b2806039233f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 23, 2023, 02:02 grarpamp <grarpamp@gmail.com> wrote:
On 8/22/23, iio7@tutanota.com <iio7@tutanota.com&g= t; wrote:
> There seems to be a bit of open (and rather old) ZFS native encryption=
> bugs which still haven't been fixed and it doesn't look like i= t is
> something that is being working on.
>
> Last night I was going to move some important files from an unencrypte= d
> dataset to a new encrypted (ZFS native) one, but then got my doubts > about doing that (looking at all the different open GitHub issues on > OpenZFS).
>
> There exist some rumors about the original company which did the ZFS >=C2=A0 native encryption work (the person doing the work left the compa= ny),
>=C2=A0 and they haven't done more since.
>
> What is the general experience running with ZFS native encryption on > FreeBSD? Is it better to use GELI for the whole pool instead?

Neither GELI, nor the rest of the crypto subsystem,
nor the kernel, nor userland... has ever undergone
anything close to a real security audit, let alone an
independent one, let alone been formally verified.

And agents, moles, malactors, bugs, and worse are running
rampant across the entire computing spectrum... from fab,
to shipping, to OS and crypto development, to magic packets,
to telecom, to phones, to firmware, software, apps, and updates,
BGP, your ISP, frontdoor, backdoor, back orifice, and more.

Your use of any crypto, on any operating system, on any
hardware platform, on any network, is entirely at your own risk.

Still lots of fun yet to be had...

#OpenFabs , #OpenHW , #OpenAudit , #FormalVerification ,
#CryptoCrowdFunding , #OpenTrust , #GuerrillaNets ,
#P2PFiber , #GNURadioRF , #PrivacyCoins , #DropGangs , ...
=

Maybe it would wo= rk to use both. Encrypt the underlying devices with geli, plus encrypt the = zfs dataset. I haven't tried this but it logically should be easy to la= yer them.

You would be p= rotected against a bug affecting either one this way, but of course the ris= k of both being compromised is still nonzero. For the best protection, perh= aps different ciphers could be used. I'm not sure what options there ar= e but I'm curious if someone in this wheelhouse could fill in my gaps.<= /div>

- Leif

--000000000000700b2806039233f5--