From owner-freebsd-geom@FreeBSD.ORG Wed Jan 1 19:50:37 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98CBF33C for ; Wed, 1 Jan 2014 19:50:37 +0000 (UTC) Received: from cargobay.net (cargobay.net [162.220.58.155]) by mx1.freebsd.org (Postfix) with ESMTP id 75CA61FD5 for ; Wed, 1 Jan 2014 19:50:37 +0000 (UTC) Received: from [192.168.0.16] (unknown [65.35.151.3]) by cargobay.net (Postfix) with ESMTPSA id 4226C1EA3; Wed, 1 Jan 2014 19:49:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: HAST + GELI? From: "Chad J. Milios" X-Mailer: iPhone Mail (11B554a) In-Reply-To: <2EB9462086A3E79F9C337122@study64.tdx.co.uk> Date: Wed, 1 Jan 2014 14:50:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <817BD375-366B-4FA4-B9E5-522617C309F6@ccsys.com> References: <49C17592-B51C-42E5-BF04-8BC4D97DA108@ccsys.com> <2EB9462086A3E79F9C337122@study64.tdx.co.uk> To: Karl Pielorz Cc: "freebsd-geom@freebsd.org" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 19:50:37 -0000 >> 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. :)=