Re: Depreciate and remove gbde

If I can open the soapbox for a moment.

If you want a secure filesystem I think that at this particular time
it would be entirely reasonable to use both gbde and geli stacked on
top of each other, assuming you have CPU/battery to spare.  (there
should be enough cores but the battery might be unhappy)

Nobody is going to go at your encrypted filesystem at the cipher
level.  The problem with using a less-testing system like either of
these is that there might be errors in setup that have reduced the
search space for the correct key.  That happens all the time.  The
protocols to set up the actual cipher aren't trivial to get right.  So
if you stack both you would guard yourself against screwups in either,
even if you use the same actual cipher for both layers.

In addition there is a fashion right now that people with lots of
brain and time go after the block chaining modes for block device
encryption.  It looks semi-ugly I'd say although not really
spectacular right now.

If you stack both gbde and geli on top of each other you can use
different block chaining modes and you would also guard yourself
against a failure there.

Just don't do it on top of a consumer SATA SSD...

Having said this, now that I looked at gbde's block chaining, it seems
it simply inherits CBC from geom_aes.c, is that right?

Martin

Yonas Yanfa wrote on Mon, Oct 19, 2015 at 08:43:00PM -0400: 
> Hi Martin, thanks, that raises some interesting points. After reading PHK's
> paper on GBDE, I can see enough differences between GDBE and GELI that
> warrant keeping GDBE.
> 
> [ At this point for me, this part is theoretical, but it's still
> interesting ] I've seen the concerned made a few times that we need to
> support existing users. That's true up to a point. There's always going to
> be a way to transition from GDBE to GELI if we really want to (eg. a
> conversion tool), or were forced to for any reason (full decrypt and
> re-encrypt), so we shouldn't be keeping GDBE in the tree solely for this
> reason alone. GDBE should be in the tree for it's technical merits (which
> I've found it does have). However, if it turns out in X years from today
> GELI can do everything GDBE can do and better, then I would say we should
> figure out a way to remove GDBE.
> 
> On Mon, Oct 19, 2015 at 7:44 PM, Martin Cracauer <cracauer_at_cons.org> wrote:
> 
> > Yonas Yanfa wrote on Sun, Oct 18, 2015 at 06:36:19AM -0400:
> > >
> > > Is there any objection to removing gbde? How many people use gbde? When
> > > have you used gbde over geli, and why?
> >
> > You would exclude all current users from accessing their existing
> > filesystems or whatever they put into that block device.
> >
> > A conversion tool would pretty much be forced to use the current
> > kernel layers (doing the block chaining in userspace would be
> > annoying), and it would be fundamentally unsafe to have your
> > half-converted filesystem on disk in case of an interruption.  Plus I
> > think GELI uses a bigger header so you might fall short by a couple of
> > bytes and you can't do anything about it on the block level with no
> > access to the filesystem.
> >
> > And people might not have their gbde units accessible right now, it
> > might be on a laptop in a closet on a different continent.
> >
> > Martin
> > --
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > Martin Cracauer <cracauer_at_cons.org>   http://www.cons.org/cracauer/
> >

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer_at_cons.org>   http://www.cons.org/cracauer/