From owner-freebsd-geom@FreeBSD.ORG Wed Jan 1 17:34:13 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E57AF708 for ; Wed, 1 Jan 2014 17:34:13 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 86EE1165B for ; Wed, 1 Jan 2014 17:34:13 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s01HY0T8021317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jan 2014 17:34:00 GMT Date: Wed, 01 Jan 2014 17:34:00 +0000 From: Karl Pielorz To: "Chad J. Milios" Subject: Re: HAST + GELI? Message-ID: <2EB9462086A3E79F9C337122@study64.tdx.co.uk> In-Reply-To: <49C17592-B51C-42E5-BF04-8BC4D97DA108@ccsys.com> References: <49C17592-B51C-42E5-BF04-8BC4D97DA108@ccsys.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 17:34:14 -0000 --On 31 December 2013 17:03:33 -0500 "Chad J. Milios" wrote: > Either way works great. Both ways have their benefits, pains and > pitfalls. I guess HAST on top of GELI means both systems share the crypto load, whereas 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 HAST on GELI is probably the better way to go. > 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? There's not a lot to elaborate - I want more redundancy for a home system with the added benefit if someone happens to steal either box - I don't want them getting 'easy access' to family photos, emails info etc. > In other cases software based full disk encryption is really only going > to thwart or inconvenience the weakest of adversaries, 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 point kinda taken :-) -Karl 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. :)= From owner-freebsd-geom@FreeBSD.ORG Sat Jan 4 21:53:05 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 06BEA7C3 for ; Sat, 4 Jan 2014 21:53:05 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1B361487 for ; Sat, 4 Jan 2014 21:53:04 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2587:f4b9:bcd2:7c53]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 87ABA4AC2D for ; Sun, 5 Jan 2014 01:53:03 +0400 (MSK) Date: Sun, 5 Jan 2014 01:53:01 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1023566295.20140105015301@serebryakov.spb.ru> To: freebsd-geom@freebsd.org Subject: "deep" gpart backup? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 21:53:05 -0000 Hello, Freebsd-geom. Is here any way to make "deep" "gpart backup | gpart restore"? Now, when I have disk with MBR, with two slices, each of which has BSD label, I need three calls of backup / restore commands with proper arguments. It looks just stupid :) -- // Black Lion AKA Lev Serebryakov