Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Oct 2015 12:06:11 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        "Julian H. Stacey" <jhs@berklix.com>
Cc:        freebsd-current@freebsd.org, Martin Cracauer <cracauer@cons.org>, Yonas Yanfa <yonas@fizk.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject:   Re: Depreciate and remove gbde
Message-ID:  <20151024190611.GE65715@funkthat.com>
In-Reply-To: <201510241559.t9OFwsiF078038@fire.js.berklix.net>
References:  <6216.1445631619@critter.freebsd.dk> <201510241559.t9OFwsiF078038@fire.js.berklix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian H. Stacey wrote this message on Sat, Oct 24, 2015 at 17:58 +0200:
> > >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[...]
> 
> I've often wondered if multiple encryption (CPU permitting) is sensible in 
> case one day some method is cracked but another stays secure.

Depends if you care about performance or not.  gbde is very slow, maybe
150MB/sec/core on a decently fast processor...  Where as geli is
~1GB/sec/core (AES-XTS)...

> There's been recent discussions on cracking algorithms at
>  http://lists.gnupg.org/pipermail/gnupg-users/2015-October/054586.html
> 
> I see man geli has:
> 	Supports many cryptographic algorithms (currently AES-XTS,
> 	AES-CBC, Blowfish-CBC, Camellia-CBC and 3DES-CBC).
> NAME section of man 1 gbde & geli both ref. GEOM.
> Skimming man 1 4 8 gbde geom I'm not sure how gbde compares.

gbde uses AES128-CBC, which is bad for modern processors that have AES-NI
instructions, as AES-CBC cannot be pipelined.

> > Nobody is going to break through the GELI or GBDE crypto, they'll
> > find their way to the keys instead, or more likely, jail you until
> > you sing.
> 
> Yes, if 'they' are physicaly present government, criminals etc.
> 
> Encryption (& perhaps multiple encryption) is nice against eg

The thing I like most about encryption is that when I RMA a bad
drive, I don't have to worry about my data leaking if I am unable
to overwrite all the data...  Also, for SSD's, where a complete
overwrite will not overwrite all the data, this helps that..

Note that even w/ drives purporting to provide hardware encryption
they don't do it very well:
http://arstechnica.com/security/2015/10/western-digital-self-encrypting-hard-drives-riddled-with-security-flaws/

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151024190611.GE65715>