From owner-freebsd-geom@FreeBSD.ORG Thu Jun 19 14:42:57 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C958106564A for ; Thu, 19 Jun 2008 14:42:57 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id E79AA8FC21 for ; Thu, 19 Jun 2008 14:42:56 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1K9L6i-00071y-40; Thu, 19 Jun 2008 15:27:24 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K9L6h-0000Fm-Pt; Thu, 19 Jun 2008 15:27:23 +0100 Date: Thu, 19 Jun 2008 15:27:23 +0100 From: Thomas Hurst To: Greg Rivers Message-ID: <20080619142723.GA97597@voi.aagh.net> Mail-Followup-To: Greg Rivers , RW , freebsd-geom@freebsd.org References: <20080618225407.1337ad03@gumby.homeunix.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Not much. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Thomas Hurst Cc: RW , freebsd-geom@freebsd.org Subject: Re: Is geli detectable? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2008 14:42:57 -0000 * Greg Rivers (gcr@tharned.org) wrote: > All but the last sector will indeed appear to be more or less random > data. But the last sector contains the geli metadata, and thus a > distinction can be made. You can prove this by running `geli dump > ` when the provider is not attached (decrypted), or by > otherwise inspecting the last sector. Yup, this is how the .eli devices magic into existance on boot/attach. onetime encrypted devices would appear to be the exception; the metadata only lives in memory. It doesn't look like it'd be that difficult to put the metadata elsewhere, and pass it manually to geli to attach a provider. Similarly I expect you could encrypt the metadata block itself, again forgoing auto-detection in favour of manually mounting; I believe TrueCrypt does this. For archival purposes, you can already geli backup metadata for storage elsewhere, and geli clear/kill it so the device is simply filled with random data (plus, apparantly, a zeroed last sector). -- Thomas 'Freaky' Hurst http://hur.st/