Re: Depreciate and remove gbde

[Jeffrey Bouquet]

On Thu, 29 Oct 2015 16:24:00 -0700, John-Mark Gurney  wrote:

> Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700:
> > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney  wrote:
> > 
> > > 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...
> > 
> > You are optimistic if you believe that.  We ($WORK) factor the cost of 
> > DOA/warranty drives into our operational budget.  They never get RMAed.  We 
> > drill them when they die.
> 
> Being a personal user, and having close to a 10% RMA rate on recent
> hard drives, that would be a bit costly...
> 
> I consider a HD defective if it's under waranty and it's performance
> drops below 80% of new, i.e. 130MB/sec normal sequential write drops
> below 100MB/sec..
> 
> The weekest point is the passphrase/passfile protecting the master
> key... In my case, I use a random passfile for these drives...  If
> someone is able to break the passfile, or the AES-256 encryption, then
> they must really want my data...  It'd be easier, even for governments,
> to do a black bag job than recover partial data (it's one drive of a
> RAIDZ array)...
> 
> -- 
>   John-Mark GurneyVoice: +1 415 225 5579
> 
>  "All that I will do, has been done, All that I have, has not."
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


FWIW I've several WD eide that corrupt with twed0... fix them with
dosdlg.exe on floppy (long test, an hour...) and they work fine as primary
eide drives a long while thereafter (not secondary on twed0...)   
in case that saves anyone some time/money...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[John-Mark Gurney]

Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700:
> On Oct 24, 2015, at 12:06 PM, John-Mark Gurney  wrote:
> 
> > 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...
> 
> You are optimistic if you believe that.  We ($WORK) factor the cost of 
> DOA/warranty drives into our operational budget.  They never get RMAed.  We 
> drill them when they die.

Being a personal user, and having close to a 10% RMA rate on recent
hard drives, that would be a bit costly...

I consider a HD defective if it's under waranty and it's performance
drops below 80% of new, i.e. 130MB/sec normal sequential write drops
below 100MB/sec..

The weekest point is the passphrase/passfile protecting the master
key... In my case, I use a random passfile for these drives...  If
someone is able to break the passfile, or the AES-256 encryption, then
they must really want my data...  It'd be easier, even for governments,
to do a black bag job than recover partial data (it's one drive of a
RAIDZ array)...

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Felix Kronlage]

Lyndon Nerenberg wrote:
> On Oct 24, 2015, at 12:06 PM, John-Mark Gurney  wrote:
>> 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...
> You are optimistic if you believe that.  We ($WORK) factor the cost of 
> DOA/warranty drives into our operational budget.  They never get RMAed.  We 
> drill them when they die.

Can only second that. One of the reasons why we work with hardware
vendors that offer Keep-your-drive warranty. That way, we get to keep
the broken drive and still get them RMA'ed. Can definitly recommend that ;)


felix

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Lyndon Nerenberg]

On Oct 24, 2015, at 12:06 PM, John-Mark Gurney  wrote:

> 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...

You are optimistic if you believe that.  We ($WORK) factor the cost of 
DOA/warranty drives into our operational budget.  They never get RMAed.  We 
drill them when they die.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Depreciate and remove gbde

[Julian H. Stacey]

> >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.
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.


> 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
- sneak thieves/ industrial spies/ remote hostile governments,
- where one must sometimes share root with others.
- scanners remote or local 
   (Scanners could be hidden in BLOBs. Anyone else worry how many
   binary BLOBs are in FreeBSD, especially ports/ ?  I started a
   list a couple of years back, got scared how many, then stopped
   after I realised a list was not maintainable & better to add a
   BLOB_HAZARD= label to ports Makefiles, but no one seemed interested ).
- Casual physical loss:
  - My brother's USB stick fell off its plastic retainer to key ring,
picture: http://www.conrad.de/ce/de/product/417197/
  - Small shiney USB sticks on desk could be attractive like jewelery
to birds such as magpies (`Elster' fly here, I stopped one thieving
a shiney foil wrapped bar, a lot heavier & bigger than a USB stick).

My data is long encrypted, I'll buy phk@ a beer if we meet somewhere :-)

Cheers,
Julian
--
Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
 Reply After previous text to preserve context, as in a play script.
 Indent previous text with >Insert new lines before 80 chars.
 Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Maxim Sobolev]

For what's worth we are using modded GBDE in one of the products to provide
copy protection for the firmware and encryption of user's data. GELI is
nice, but it's way much more end-user oriented. Also GBDE code is very
stable, which may look bad from somebody using it to protect his pr0n
collection, but from the PoV of us as ISV we have very little trouble
porting our changes from FreeBSD 6 that we've started with originally to 7,
8, 9 and the FreeBSD 11 today. I would be really sorry to see it nuked from
the FreeBSD without any good technical reason. Just my CAD0.02c.

On Sat, Oct 24, 2015 at 8:58 AM, Julian H. Stacey  wrote:

> > >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.
> 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.
>
>
> > 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
> - sneak thieves/ industrial spies/ remote hostile governments,
> - where one must sometimes share root with others.
> - scanners remote or local
>(Scanners could be hidden in BLOBs. Anyone else worry how many
>binary BLOBs are in FreeBSD, especially ports/ ?  I started a
>list a couple of years back, got scared how many, then stopped
>after I realised a list was not maintainable & better to add a
>BLOB_HAZARD= label to ports Makefiles, but no one seemed interested ).
> - Casual physical loss:
>   - My brother's USB stick fell off its plastic retainer to key ring,
> picture: http://www.conrad.de/ce/de/product/417197/
>   - Small shiney USB sticks on desk could be attractive like jewelery
> to birds such as magpies (`Elster' fly here, I stopped one thieving
> a shiney foil wrapped bar, a lot heavier & bigger than a USB stick).
>
> My data is long encrypted, I'll buy phk@ a beer if we meet somewhere :-)
>
> Cheers,
> Julian
> --
> Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich
> http://berklix.com
>  Reply After previous text to preserve context, as in a play script.
>  Indent previous text with >Insert new lines before 80 chars.
>  Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[John-Mark Gurney]

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."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <20151023192353.ga95...@cons.org>, Martin Cracauer writes:

>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[...]

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.

But neither GELI og GBDE alone or together give you a secure filesystem.

The very first requirement for a secure filesystem is that you can
trust the computer it is mounted on.

No commercially available smartphone, tablet, laptop, server or
desktop computer can be trusted by the owner at this point in time.

Want a secure filesystem ?

First step is to mount it on RaspBerry or Beaglebone without network
connectivity...

But more importantly:  There is no technical fix for lost privacy,
that is a political problem, and it must be solved by political
means.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Martin Cracauer]

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  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    http://www.cons.org/cracauer/
> >

-- 
%%%
Martin Cracauer    http://www.cons.org/cracauer/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Anton Shterenlikht]

>GBDE is for when the user is in danger.

In danger of what?
Please elaborate.

>From the handbook, it is not clear at all
that the two encryption methods are designed
to defend against different threats.

Maybe I'm using the wrong one...

Thank you

Anton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[NGie Cooper]

> On Oct 20, 2015, at 00:29, Poul-Henning Kamp  wrote:
> 
> 
> In message <201510200645.t9k6jaam004...@mech-as222.men.bris.ac.uk>, Anton 
> Shterenlikht writes:
>>> GBDE is for when the user is in danger.
>> 
>> In danger of what?
>> Please elaborate.
> 
> Read the paper:
> 
>   http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
> 
> Or use the TL;DR version in the slides:
> 
>   http://phk.freebsd.dk/pubs/bsdcan-04.slides.gbde.pdf

Thank you for the pointers. This should be summarized in the documentation 
though, if it’s worth noting.
Cheers,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <5625d422.4040...@fizk.net>, Yonas Yanfa writes:

>> Think human rights activists for instance.
>
>Couldn't they use a fake email address and Tor to communicate 
>anonymously? I'd be surprised if they aren't already.

If you think being a human rights activist is that simple, you
really have *no* idea...

For a lot of them, using Tor would instantly blow their cover.

We're not talking about people who wear Amnesty International
T-shirts or who call themselves "human rights activists" when the
pass through immigration.

We're talking about people who for all practical purposes have a
job as hard or harder than "real" spies.

They do not have the the support and resources of their own government,
they do not have a spare diplomatic passport and a new identity
waiting for them at the embassy, and they certainly cannot afford
those sunglasses.

Getting it wrong on crypto or comms-footprint will at the very least
cost them a year in some Elbonian mud-jail, worst case they die in
a "traffic accident" or "commit suicide" in a turkish air-port
toilet.


>but we should improve the Handbook so gdbe vs. geli 
>strengths and weaknesses are better explained.

By all means go for it!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <201510200841.t9k8fngy005...@mech-as222.men.bris.ac.uk>, Anton 
Shterenlikht writes:

>Am I correct that the papers are from 2003 and 2004
>respectively. Has much changed in gbde since then?

Nope.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Anton Shterenlikht]

>From p...@phk.freebsd.dk Tue Oct 20 10:08:55 2015
>
>>Am I correct that the papers are from 2003 and 2004
>>respectively. Has much changed in gbde since then?
>
>Nope.

One thing that puzzled me about the way gbde
is integrated with the FreeBSD boot sequence is
that it's not possible to boot without entering
the correct gbde pass phrase.
I assumed that if the correct pass phrase is not
entered the specified number of times, three by
default, the boot should proceed without attaching
the encrypted partition.
But at present, if the correct pass phrase 
is not entered, the system goes into a single
user mode, but exiting from it to a multi-user mode
again gets one to gbde pass phrase prompt.
So it's not possible to boot at all without
attaching the gbde encrypted partition. 
Perhaps this can be configured via some rc* options?

The reason is that even a laptop can have multiple
users, not all of whom need/should mount any or all
encrypted partitions.

And a wish - please describe "nuke" and "destroy"
options more explicitly. The man page is extremely
terse on this. Given the seriosness of the consequences -
loss of all data on encrypted partition(?) - would
be great to know exactly what would happen.
The man page says both options will invalidate the
masterkey. Does this mean that encrypted data
cannot be recovered?
This is my guess, based on reading your 2 papers.

Many thanks for gbde.

Anton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Anton Shterenlikht]

>> In message <201510200645.t9k6jaam004...@mech-as222.men.bris.ac.uk>, Anton 
>> Shterenlikht writes:
 GBDE is for when the user is in danger.
>>> 
>>> In danger of what?
>>> Please elaborate.
>> 
>> Read the paper:
>> 
>>  http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
>> 
>> Or use the TL;DR version in the slides:
>> 
>>  http://phk.freebsd.dk/pubs/bsdcan-04.slides.gbde.pdf

Thanks, I get it now.
Am I correct that the papers are from 2003 and 2004
respectively. Has much changed in gbde since then?

Anton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Yonas Yanfa]

On 10/20/2015 01:27, Poul-Henning Kamp wrote:


In message 
, NGie 
Cooper writes:


1. Why are there 2 competing technologies?

They are not competing, they support two very different threat models.


We need to make this a lot more clear in the Handbook. John-Mark is 
taking the charge here.



3. Is there a gain/loss for removing gbde?

Yes, you alienate a lot of users who very often are not even in a
position to tell you they run FreeBSD.

Think human rights activists for instance.


Couldn't they use a fake email address and Tor to communicate 
anonymously? I'd be surprised if they aren't already.


As I said to Martin, this point keeps coming up as though its grounds 
alone to leave gdbe in the tree forever. gdbe should stand on its 
technical merits. After reading your paper on gdbe, I understand those 
merits a lot better, but we should improve the Handbook so gdbe vs. geli 
strengths and weaknesses are better explained.






4. Why is it marked experimental [still]?

To make people think.



What it made me think was - "this software has been here for so many 
years and is still experimental and suspect??? It must have issues. Why 
is it still in the tree?"


Yonas

--

Yonas Yanfa
In Love With Open Source
Drupal  :: GitHub 
 :: Mozilla 
 :: iPhone 


fizk.net | yo...@fizk.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <201510200645.t9k6jaam004...@mech-as222.men.bris.ac.uk>, Anton 
Shterenlikht writes:
>>GBDE is for when the user is in danger.
>
>In danger of what?
>Please elaborate.

Read the paper:

http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

Or use the TL;DR version in the slides:

http://phk.freebsd.dk/pubs/bsdcan-04.slides.gbde.pdf


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Anton Shterenlikht]

I use gbde.
Can switch to geli, if required,
but please provide detailed instructions
for switching before removing gbde.

Anton
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Slawa Olhovchenkov]

On Mon, Oct 19, 2015 at 01:52:05AM -0700, Perry Hutchison wrote:

> Anton Shterenlikht  wrote:
> 
> > I use gbde.
> > Can switch to geli, if required,
> > but please provide detailed instructions
> > for switching before removing gbde.
> 
> Such instructions would presumably be included in the UPDATING
> entry.
> 
> An additional consideration:  If there is no convert-in-place
> mechanism -- i.e. the only way to convert a gbde FS to geli is to
> backup, wipe, and restore (thus involving considerable downtime)
> -- it will give some unknown number of production users a strong
> motivation to freeze at [last version of FreeBSD to include gbde
> support].

This must be show-stoper for removing gbde.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Perry Hutchison]

Anton Shterenlikht  wrote:

> I use gbde.
> Can switch to geli, if required,
> but please provide detailed instructions
> for switching before removing gbde.

Such instructions would presumably be included in the UPDATING
entry.

An additional consideration:  If there is no convert-in-place
mechanism -- i.e. the only way to convert a gbde FS to geli is to
backup, wipe, and restore (thus involving considerable downtime)
-- it will give some unknown number of production users a strong
motivation to freeze at [last version of FreeBSD to include gbde
support].
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Julian H. Stacey]

Slawa Olhovchenkov wrote:
> On Mon, Oct 19, 2015 at 01:52:05AM -0700, Perry Hutchison wrote:
> 
> > Anton Shterenlikht  wrote:
> > 
> > > I use gbde.
> > > Can switch to geli, if required,
> > > but please provide detailed instructions
> > > for switching before removing gbde.
> > 
> > Such instructions would presumably be included in the UPDATING
> > entry.
> > 
> > An additional consideration:  If there is no convert-in-place
> > mechanism -- i.e. the only way to convert a gbde FS to geli is to
> > backup, wipe, and restore (thus involving considerable downtime)
> > -- it will give some unknown number of production users a strong
> > motivation to freeze at [last version of FreeBSD to include gbde
> > support].
> 
> This must be show-stoper for removing gbde.

Yes.

Someone with a commit bit could hopefully add a line or 2 to man gbde, that
as gbde was around in 5.0-RELEASE 2003, gbde is No Longer experimental,
it's stable & in use; newbies need not be scared.

https://www.freebsd.org/cgi/man.cgi?query=gbde=0=0=FreeBSD+5.0-RELEASE=default=html

which was released pre 2006
https://www.freebsd.org/security/unsupported.html
Jan 16 2003
https://svnweb.freebsd.org/base/release/5.0.0/README?view=markup

Jan 16 16:56:23 2003 
https://svnweb.freebsd.org/base/release/5.0.0/sbin/gbde/gbde.8?revision=109388=markup

Cheers,
Julian
--
Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
 Reply After previous text to preserve context, as in a play script.
 Indent previous text with >Insert new lines before 80 chars.
 Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Ed Maste]

On 19 October 2015 at 16:50, John-Mark Gurney  wrote:
> O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:
>> For me, I'd like to know what is the benefit/performance of each technique 
>> and
>> a clear preparation of each ones advantages over the other. That would make 
>> the
>> decission process much easier and hopefully would not scare people away and
>> announce "FreeBSD does not have a, b, c, ..." ...
>
> So, one thing that the docs talk about is that geli uses the crypto(9)
> framework.  This doesn't mean much on it's own, but if you have a machine
> with AES-NI instructions or an accelerator card that supports the cipher
> mode used, then you can get faster performance of hardware off load,
> while gbde uses the software only routines which are slow..

John-Mark, thanks for listing these differences. This is the sort of
information we should have available for end users to help choose one
or the other -- this info ought to make it into the handbook.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Julian H. Stacey]

Hi, Reference:
> From: John-Mark Gurney 
> Date: Mon, 19 Oct 2015 13:50:08 -0700

John-Mark Gurney wrote:
> So, one thing that the docs talk about is that geli uses the crypto(9)

Interesting.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html
Could benefit from a link to John-Mark Gurney's 
http://lists.freebsd.org/pipermail/freebsd-current/2015-October/057855.html

Cheers,
Julian
--
Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
 Reply After previous text to preserve context, as in a play script.
 Indent previous text with >Insert new lines before 80 chars.
 Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[John-Mark Gurney]

O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:
> For me, I'd like to know what is the benefit/performance of each technique and
> a clear preparation of each ones advantages over the other. That would make 
> the
> decission process much easier and hopefully would not scare people away and
> announce "FreeBSD does not have a, b, c, ..." ...

So, one thing that the docs talk about is that geli uses the crypto(9)
framework.  This doesn't mean much on it's own, but if you have a machine
with AES-NI instructions or an accelerator card that supports the cipher
mode used, then you can get faster performance of hardware off load,
while gbde uses the software only routines which are slow..

I have put work into making AES-XTS very fast on AES-NI capable
machines...  On my test machine, I get about 1GB/sec on gzero... This
is close to real world (assuming infitely fast disc) vs. just running
the algorithm and posting those results (which result in 2GB/sec+ on
the same machine)...  You will not be able to achive that level of
performance w/ gbde.

Also, gbde uses CBC, while having some better crypto properties than
XTS, would require significant rewrite of gbde to make it perform...

I just noticed that the handbook also fails to mention that geli has
a mode that will verify the integrity of data which gbde does not have..

As we have discovered, if you can't authenticate your data, you really
can't trust it...  I personally have decided that I will use ZFS's sha256
checksums of the data as my integrity protection mechanism..  It is
highly unlikely that an attacker would be able to corrupt two AES-XTS
blocks to cause the sha256 checksum to match what they corrupted other
blocks to become...

So, in this reguard, if you run gbde w/ ZFS w/ sha256 checksums, then
are equivalent (besides the performance difference)...

I personally run geli encryption on my 8 drive ZFS array at home.

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Yonas Yanfa]

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  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    http://www.cons.org/cracauer/
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Martin Cracauer]

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    http://www.cons.org/cracauer/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[RW]

On Mon, 19 Oct 2015 06:19:30 +0200
O. Hartmann wrote:


> When I looked for FreeBSD's encryption, I stopped by GELI. Because of
> it's easy-to-use AND the 'experimental' tag in the handbook! 
> 
> For me, I'd like to know what is the benefit/performance of each
> technique and a clear preparation of each ones advantages over the
> other.

IIRC gbde allows the passphrase to be verified even after the
master-keys have been deleted. The point is to demonstrate that the
passphrase is not being withheld, and the data unrecoverable.

AFAIK that's the only advantage it has over geli. geli supports
hardware acceleration, it's faster in software too. It's more resistant
to dictionary/brute force attacks against the passphrase because of
its PKCS #5 support. It supports a wider range of options and
ciphers/modes. And though it's newer, it's undoubtedly had far more
user-hours of use. Also I don't remember the details, but I think
there's an operation that's atomic in geli, but not in gbde, that gives
gbde a greater risk of data corruption.

I certainly wouldn't like to see gbde removed but I think it is
unfortunate that it's given slightly greater prominence in the handbook
than geli. geli is the right choice for most people.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[NGie Cooper]

On Mon, Oct 19, 2015 at 4:44 PM, Martin Cracauer  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.

For the number of replies Yonas received saying "no, don't do that --
someone might be using it" -- the reason why Yonas asked the question
is valid given the information that was presented.

1. Why are there 2 competing technologies?
2. Is one technologically superior to the other (performance, capability, etc)?
3. Is there a gain/loss for removing gbde?
4. Why is it marked experimental [still]?

Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[John-Mark Gurney]

Ed Maste wrote this message on Mon, Oct 19, 2015 at 17:13 -0400:
> On 19 October 2015 at 16:50, John-Mark Gurney  wrote:
> > O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:
> >> For me, I'd like to know what is the benefit/performance of each technique 
> >> and
> >> a clear preparation of each ones advantages over the other. That would 
> >> make the
> >> decission process much easier and hopefully would not scare people away and
> >> announce "FreeBSD does not have a, b, c, ..." ...
> >
> > So, one thing that the docs talk about is that geli uses the crypto(9)
> > framework.  This doesn't mean much on it's own, but if you have a machine
> > with AES-NI instructions or an accelerator card that supports the cipher
> > mode used, then you can get faster performance of hardware off load,
> > while gbde uses the software only routines which are slow..
> 
> John-Mark, thanks for listing these differences. This is the sort of
> information we should have available for end users to help choose one
> or the other -- this info ought to make it into the handbook.

I'm working on updating the section now...

Also realized we should include verbage to say that it's best to use
page size sectors when possible to reduce overhead of the crypto...

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message 
, NGie 
Cooper writes:

>1. Why are there 2 competing technologies?

They are not competing, they support two very different threat models.

>3. Is there a gain/loss for removing gbde?

Yes, you alienate a lot of users who very often are not even in a
position to tell you they run FreeBSD.

Think human rights activists for instance.

>4. Why is it marked experimental [still]?

To make people think.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Warren Block]

On Mon, 19 Oct 2015, John-Mark Gurney wrote:


Ed Maste wrote this message on Mon, Oct 19, 2015 at 17:13 -0400:

On 19 October 2015 at 16:50, John-Mark Gurney  wrote:

O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:

For me, I'd like to know what is the benefit/performance of each technique and
a clear preparation of each ones advantages over the other. That would make the
decission process much easier and hopefully would not scare people away and
announce "FreeBSD does not have a, b, c, ..." ...


So, one thing that the docs talk about is that geli uses the crypto(9)
framework.  This doesn't mean much on it's own, but if you have a machine
with AES-NI instructions or an accelerator card that supports the cipher
mode used, then you can get faster performance of hardware off load,
while gbde uses the software only routines which are slow..


John-Mark, thanks for listing these differences. This is the sort of
information we should have available for end users to help choose one
or the other -- this info ought to make it into the handbook.


I'm working on updating the section now...

Also realized we should include verbage to say that it's best to use
page size sectors when possible to reduce overhead of the crypto...


I can help with markup and editing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <20151019234855.4ed82...@gumby.homeunix.com>, RW writes:

>I certainly wouldn't like to see gbde removed but I think it is
>unfortunate that it's given slightly greater prominence in the handbook
>than geli. geli is the right choice for most people.

This I fully agree with.

GELI is fine if your threatmodel is a stolen laptop.

GBDE is for when the user is in danger.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Julian H. Stacey]

Yonas Yanfa wrote:
> Hi,
> 
> It seems geli is the standard way of encrypting disks. It's extremely 
> flexible and usually recommended by the community over gbde. Moreover, 
> geli is mentioned a lot more in the mailing lists and forums.

& global community uses DOS-FS more, & mentions MS more than BSD. ;-)
Popularity is not sole index of what everyone should be constrained to use.


> gbde's man page explicitly says that gbde is experimental and should be 
> considered suspect.

Just an old cautious initial description, that I recall long predates geli.


> That seems reason enough to finally depreciate and 
> remove it in favour of geli.

No, very naieve.  No need to remove gbde & disrupt existing users.
Perhaps a reason to re-balance cautious description in both.


> The Encrypting Disk Partitions page in the Handbook discusses gbde 
> first, and describes geli as an alternative. This seems odd, shouldn't 
> this be the other way around?

It was written in historical order.


> Is there any objection to removing gbde?

Yes.  Daft to disrupt users.


> How many people use gbde?

Not so useful to ask on Current@ which tends to use the latest tools
eg geli; try hackers@ or questions@ etc, realise usage of BSD does
not require registration or membership of Any BSD mail list or
forum. Usage of GBDE more so.  Gbde could well be essential on
production servers, but unless admins are also programmers on
current@, they won't even see your idea to remove gdbe.


> When 
> have you used gbde over geli, and why?

Gbde came first, some won't have needed more or wasted time to learn an
alternate they did not need.  Others may have reasons they may not publish.

Without analysis, deprecating gbde is not sensible, & removal worse.
Please research & contribute a handbook section, with URLs & text
comparing gbde & geli (& other crypt FS in ports/ ?), including eg:

- Processor & IO load of both, 
- Crack testing of both if any, 
- History of code review & quality of both. etc
- Patent liabilities of either ? licensing ?
- Compatability of both with other OSs if any,
- Any possiblities for standards approvals of either by any bodies (that
  usually requires funding, so with 2 maybe more chance of 1 being funded ?)

Cheers,
Julian
--
Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
 Reply After previous text to preserve context, as in a play script.
 Indent previous text with >Insert new lines before 80 chars.
 Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[O. Hartmann]

On Mon, 19 Oct 2015 01:29:36 +0200
"Julian H. Stacey"  wrote:

> 
> Yonas Yanfa wrote:
> > Hi,
> > 
> > It seems geli is the standard way of encrypting disks. It's extremely 
> > flexible and usually recommended by the community over gbde. Moreover, 
> > geli is mentioned a lot more in the mailing lists and forums.
> 
> & global community uses DOS-FS more, & mentions MS more than BSD. ;-)
> Popularity is not sole index of what everyone should be constrained to use.
> 
> 
> > gbde's man page explicitly says that gbde is experimental and should be 
> > considered suspect.
> 
> Just an old cautious initial description, that I recall long predates geli.

An indicator for the fact that the documentation is not well maintained and
probably the source for many confusion! Descriptions and concepts seem to have
a state as when the developer issued its code/project - and then never came
back maintaining documentation as the service/system/package evolves ... 

The main question here is: do I need to dip deeply into system's development
and poke from the "nerds" informations for the usage of FreeBSD - or should
someone new or more superficial consult documentation?

> 
> 
> > That seems reason enough to finally depreciate and 
> > remove it in favour of geli.
> 
> No, very naieve.  No need to remove gbde & disrupt existing users.
> Perhaps a reason to re-balance cautious description in both.

Well, for avoiding disruptions and having progress there is the invention of
releases and associated numbers. Sometimes it is innovative to cut of stuff in
favour of progression. That is my overall opionion. Legacy releases can also be
maintained.

Back to the subject: The documentation of both GELI and GBDE lack in explaining
why the one is better/more suitable than the other! I have just sneaked into
Luca's book and he drowns  both encrypting systems in a sea of words without a
clear workout of the benefits.

When I looked for FreeBSD's encryption, I stopped by GELI. Because of it's
easy-to-use AND the 'experimental' tag in the handbook! 

For me, I'd like to know what is the benefit/performance of each technique and
a clear preparation of each ones advantages over the other. That would make the
decission process much easier and hopefully would not scare people away and
announce "FreeBSD does not have a, b, c, ..." ...


> 
> 
> > The Encrypting Disk Partitions page in the Handbook discusses gbde 
> > first, and describes geli as an alternative. This seems odd, shouldn't 
> > this be the other way around?
> 
> It was written in historical order.

My suggestion would be: Set atop a small section describing the benefits of
each system and then dip into deeper waters later for each one. 

> 
> 
> > Is there any objection to removing gbde?
> 
> Yes.  Daft to disrupt users.
> 
> 
> > How many people use gbde?
> 
> Not so useful to ask on Current@ which tends to use the latest tools
> eg geli; try hackers@ or questions@ etc, realise usage of BSD does
> not require registration or membership of Any BSD mail list or
> forum. Usage of GBDE more so.  Gbde could well be essential on
> production servers, but unless admins are also programmers on
> current@, they won't even see your idea to remove gdbe.
> 
> 
> > When 
> > have you used gbde over geli, and why?
> 
> Gbde came first, some won't have needed more or wasted time to learn an
> alternate they did not need.  Others may have reasons they may not publish.
> 
> Without analysis, deprecating gbde is not sensible, & removal worse.
> Please research & contribute a handbook section, with URLs & text
> comparing gbde & geli (& other crypt FS in ports/ ?), including eg:
> 
> - Processor & IO load of both, 
> - Crack testing of both if any, 
> - History of code review & quality of both. etc
> - Patent liabilities of either ? licensing ?
> - Compatability of both with other OSs if any,
> - Any possiblities for standards approvals of either by any bodies (that
>   usually requires funding, so with 2 maybe more chance of 1 being funded ?)
> 
> Cheers,
> Julian
> --
> Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
>  Reply After previous text to preserve context, as in a play script.
>  Indent previous text with >  Insert new lines before 80 chars.
>  Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Allan Jude]

On 2015-10-18 06:36, Yonas Yanfa wrote:
> Hi,
> 
> It seems geli is the standard way of encrypting disks. It's extremely
> flexible and usually recommended by the community over gbde. Moreover,
> geli is mentioned a lot more in the mailing lists and forums.
> 
> gbde's man page explicitly says that gbde is experimental and should be
> considered suspect. That seems reason enough to finally depreciate and
> remove it in favour of geli.
> 
> The Encrypting Disk Partitions page in the Handbook discusses gbde
> first, and describes geli as an alternative. This seems odd, shouldn't
> this be the other way around?
> 
> Is there any objection to removing gbde? How many people use gbde? When
> have you used gbde over geli, and why?
> 
> Cheers,
> Yonas
> 

It is my understanding that GDBE has some different goals, and works in
different circumstances. I know Michael W. Lucas has written about it in
his books.

While I think it isn't a bad idea to put GELI first in the handbook, I
don't see any reason to remove gdbe.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Depreciate and remove gbde

[Poul-Henning Kamp]

In message <5623846b.6000...@freebsd.org>, Allan Jude writes:

>While I think it isn't a bad idea to put GELI first in the handbook, I
>don't see any reason to remove gdbe.

I don't see any reason to remove gbde, and would consider any such
suggestion somewhat suspect, given the set of users I know about.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"