Date: Wed, 1 Jan 2014 14:50:23 -0500 From: "Chad J. Milios" <milios@ccsys.com> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org> Subject: Re: HAST + GELI? Message-ID: <817BD375-366B-4FA4-B9E5-522617C309F6@ccsys.com> In-Reply-To: <2EB9462086A3E79F9C337122@study64.tdx.co.uk> References: <DEDAAAFBF4A1B918B9D76639@study64.tdx.co.uk> <49C17592-B51C-42E5-BF04-8BC4D97DA108@ccsys.com> <2EB9462086A3E79F9C337122@study64.tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Either way works great. Both ways have their benefits, pains and >> pitfalls. >=20 > I guess HAST on top of GELI means both systems share the crypto load, wher= eas GELI ontop of HAST means one box ends up doing the crypto work for both '= sides' of the HAST devices... [if I've got that the right way round] - so HA= ST on GELI is probably the better way to go. They don't share the work because at that point there has become twice the w= ork to be done. >> It depends on your use case, configuration, hardware, >> adversaries, etc. Like most security solutions, the devil, and >> weaknesses, lay in the details, like network engineering and key >> management. Care to elaborate for us? >=20 > There's not a lot to elaborate - I want more redundancy for a home system w= ith the added benefit if someone happens to steal either box - I don't want t= hem getting 'easy access' to family photos, emails info etc. GELI atop HAST is going to leave the slave with less work to do, avoid the r= equirement for the key to be in the slave until failover time and give you l= ess to worry about regarding securing the network between them. You just nee= d to make sure you have that key ready when the slave is needed and that it'= s a current key (if you ever rekey). A side note, for your use you might consider ZFS snap/send/receive (or rsync= on UFS) in lieu of HAST. Mirrors really shouldn't be considered as backups b= ecause a virus or human mistake would blow away both copies simultaneously. One must be careful to not confuse availability with redundancy though they d= o overlap a lot. HAST may give you the benefits you're looking for with less= ongoing procedure, as a true backup system/procedure generally takes more o= ngoing involvement than mirroring something. >> In other cases software based full disk encryption is really only going >> to thwart or inconvenience the weakest of adversaries, >=20 > Hehe - if that means the person who breaks in and steals it just scraps it= rather than gets to go through all the data - that's fine by me :) But poin= t kinda taken :-) >=20 > -Karl Yeah the 80/20 rule is more like the 98/2 rule when it comes to the common t= hief. :)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?817BD375-366B-4FA4-B9E5-522617C309F6>