From owner-freebsd-geom@FreeBSD.ORG Wed Jun 19 07:17:25 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DBE46512 for ; Wed, 19 Jun 2013 07:17:25 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id A171B1D8E for ; Wed, 19 Jun 2013 07:17:25 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w16so3514324vbb.9 for ; Wed, 19 Jun 2013 00:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CN5Ah0rZB/UJsIm8pi9vmT6Z2hmcje0lDXWYM3/gYLY=; b=XbJodHlNPU2ZzJAscZFSUPJmx30vlF5ReVh52NJ9DlHuMsSll8O2pJznubXqoNV12g O+NhzunAjkgQsRqygtwnGy2Rzrb1GllP7ByareSqFf+bPp5a2D2S/28snmVqHXrFFle8 lT2mNtH0C1tEGsVXEhysGneHbOm54AHKiY0/622BZmMp8JmHx+uEfPI+56rqoPDl44zo JL4ZCmAGKwWRKEWPhcKQN8P7d4NI8ZcTpJEAHJk+zwePhBmaoTxoteJgL9hCo2Hbnzzc fOxWpMkdBGfOH8pecGUcIj+O6Aj8GkfMT0XbO4xey/NZkiJbMkNbj/YnVc3G6IS3d3VC Wl2g== MIME-Version: 1.0 X-Received: by 10.220.48.73 with SMTP id q9mr220593vcf.36.1371626245052; Wed, 19 Jun 2013 00:17:25 -0700 (PDT) Received: by 10.221.16.131 with HTTP; Wed, 19 Jun 2013 00:17:24 -0700 (PDT) Date: Wed, 19 Jun 2013 03:17:24 -0400 Message-ID: Subject: geli external header (metadata) From: grarpamp To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:17:25 -0000 > I made a patch to support of external header (metadata) on GEOM ELI (geli) > System: FreeBSD 9-STABLE r250964 i386 > geli patch - http://pastebin.com/UGpnMN19 > regresion patch - http://pastebin.com/hJVkTpJZ It would be nice to see this option or some similar fix implemented. It's plausible (perhaps even at to deniability), for someone to have a disk full of random data if that is part of their disk testing or wipe for reuse strategy as well as other applications where random data is used. But having a sector on that very same random media or system that screams 'GELI' and matches g_eli.h would seem not a good idea at all. GELI thereby earns a higher place on the list of cryptos tried to find brute access, or to examine its implementation closely to find a weak access. Much better to offer detachment of metadata for those who prefer it and do not mind use of USB or other means to store and associate passphrase, keyfile and metadata. Simple detachment is good, but not an encrypted solution... In the longer term, incorporating access to metadata after the passphrase/keyfile entry process (under a new encrypted metadata scheme) could be better. It would then appear random. And so even if it was still placed alongside as a separate automatic sector for the simplest end user model, it would not appear any different. It may even be a useful option (depending on how the user expects to use the main data, such as with some app that writes to the whole, or most of the, extent every time) to have the encrypted metadata change, such as by including a timestamp at attach/detach/some_kernel_time, so that, if still alongside, it does not appear to an observer over time to be a static blob, which could give away info about what the extent is for. Whether the data covers an entire device, slice, partition, file or some other full or partial extent... it just does not seem good at all to have this unencrypted bit there saying: 'Hello, I'm GELI'. > I'd much prefer to have this implemented without the need of > storing metadata outside. If GELI presents a 1:1 crypt:clear device, there's no way to put the metadata within those same number of presented sectors, it would be obliterated. It would have to be outside, or accept all metadata parameters by the command line, for which a separate metadata file/sector is easier to manage. Then again, use of 'aalgo' presents fewer sectors so there is maybe a method there.