Date: Sat, 15 Sep 2018 12:37:46 -0700 From: Lee Brown <leeb@ratnaling.org> To: freebsd-geom@freebsd.org Subject: Re: geli - why do I need a keyfile Message-ID: <CAFPNf59nWkyodPnnCifytshCVafGNg3JTnYDcHgL6GvZ=sXmVQ@mail.gmail.com> In-Reply-To: <20180915201819.50ac10a3@gumby.homeunix.com> References: <CAFPNf588xqRYZRoCACr2n_NyfMsMvrXPR4_DjWy4evBY_1HaAQ@mail.gmail.com> <20180915201819.50ac10a3@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 15, 2018 at 12:18 PM, RW via freebsd-geom < freebsd-geom@freebsd.org> wrote: > On Fri, 14 Sep 2018 17:55:58 -0700 > Lee Brown wrote: > > > I want to create a geli provider as authentication only, no password, > > no encryption. I do: > ... > > Instead: > > # echo " " > /tmp/key > > solves that issue, but I still don't get why I even need a key file > > with -e NULL? > > Because HMAC itself needs an encrypted secret key, otherwise anyone > could write to the device without it being detectable. > > Without a securely entered passphase, or a passfile on removable media, > HMAC doesn't provide any authentication, it just detects bitrot and > naive attempts to modify the filesystem. > > Thanks for the explanation, in retrospect I should have read up on HMAC. That's precisely my use-case data integrity verification only. I'm building a RAID1 gmirror on top of 2 geli providers, so if a disk rots it's detected. Now I just need to test how the gmirror reacts when the underlying geli faults. Much appreciated -- lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPNf59nWkyodPnnCifytshCVafGNg3JTnYDcHgL6GvZ=sXmVQ>