From owner-freebsd-geom@FreeBSD.ORG Sat Jun 9 20:58:10 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7854F1065670 for ; Sat, 9 Jun 2012 20:58:10 +0000 (UTC) (envelope-from john@saltant.com) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4318FC0C for ; Sat, 9 Jun 2012 20:58:10 +0000 (UTC) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by hapkido.dreamhost.com (Postfix) with ESMTP id DB75E78333 for ; Sat, 9 Jun 2012 14:00:34 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id BC9CC594059 for ; Sat, 9 Jun 2012 13:57:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=saltant.com; h=message-id:date :from:mime-version:to:subject:content-type: content-transfer-encoding; q=dns; s=saltant.com; b=cGmzDJj8kmVyV qcpk1w1scVkBBnV4EsvGn5GS2A+hqmoL53uLUZy67uS/AhkfzcRiFb+6j9YhhMcA YLXt8EPo0DVIsbvl3LtATpuPBzGjkzvD79aiAFhovKnrIv+MyxxuQKzNa0r31Y/9 AShpoty+N0Xc87AwHIavzxJvcvmPs8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:subject:content-type: content-transfer-encoding; s=saltant.com; bh=kbfFlg8b8vxh7YBiWIu 8rZ93DMQ=; b=e0JvkvZNp6UhD28bxGPuZdYB3sshLPEQTYbGOa9ZmZllnYiERWc CQ8cHFmxYg9Z3mRMY1XCfxSjtqUudpMsY4BqTCytbkjB8FjJExKZRXMuo6YiECnC T/624QkDXCrZfzurxMk+SgLF66aMuroDrgF0DOj9o1ZCmahNnVveaX2s= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 910D9594058 for ; Sat, 9 Jun 2012 13:57:58 -0700 (PDT) Message-ID: <4FD3B8D5.7030906@saltant.com> Date: Sat, 09 Jun 2012 16:57:57 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Scope and purpose of each kind geli key 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: Sat, 09 Jun 2012 20:58:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello freebsd-geom@, I recently started using geli and found it necessary to read a bunch of source code to supplement the manpages and Handbook sections. In particular, there are several different kinds of keys (and sources of key material), but they are not clearly differentiated in the docs. Of course, one need not understand the entire geli architecture and theory of operation in order to use it, but a bit more context would make things easier. So, the purpose of this inquiry is twofold: first, to sanity check what I think I learned from my studies; second, to find out if others would find it useful for me to take a swipe at integrating this information into the docs. Master Key - ---------- There is exactly one Master Key per provider, and it never changes for the life of the provider. It is generated in userland upon init (or onetime) and the user can select the key length (-l). Up to two, encrypted copies of the Master Key can be stored in the provider metadata. Each copy is encrypted with a Key Encrypting Key derived from a User Key. Storage Key - ----------- The Storage Key(s) are deterministically derived by the kernel and cached in memory during operation. Each is generated from the Master Key and is based on the block offset. The total number of Storage Keys used by a given provider depends on the size of the provider; one Storage Key per 2^20 blocks. A block's offset is used as an Initialization Vector (IV) when encrypting or decrypting its data with the applicable Storage Key. User Key - -------- Upon init, attach, setkey, and resume, the user provides a User Key comprised of one or more User Key components; files (-k, -K), a passphrase, or stored passphrases (-j, -J). All components are processed in userland to generate a Key Encrypting Key which is used to access one of the two, encrypted Master Key copies stored in the provider metadata. Key Encrypting Key - ------------------ Each Key Encrypting Key is generated from a User Key and used to encrypt a copy of the Master Key on init or setkey, and to decrypt a copy of the Master Key on attach, setkey, or resume. For my sake and the sake of future mailing list archaeologists, are there any errors or significant ambiguities in my description? Once I've addressed any problems, would this, or something like it, be a welcome addition to the manpage and/or the Handbook? If so, is the level sufficient, or would more detail about salt, hashes, and so forth be appropriate? I will solicit editorial input in the event that this is going to see the light of day as a patch attached to a PR. Regards, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP07jVAAoJEEdKvTwaez9wph8H/2QiVPg9uEBqC/uY8kF+Dj0t TMIglXexx5D8b+AVxi3RSivm8atIDp9JqnUHM+C76N4qGzvd/cRTlMMqxuZIdMha FIX2LGp9yvIuVbMJXAKoFKIte2lNKo3v75U6EmX5Bv/YLwIO8y57cpIXxz5W7tLJ 53+5n46ChUp9Kcfdusls0lpsqe72MBainq4maJlnW2TfKWlOiXHBkg0FbpcCPSPh k/Nic/yyCPThD55E+DJy9XU9FKnVUy+1yA8IGnVuwoOBQgFCVXHd0bbqDRhqPG65 SrHmxE6iKYOVBkw1NoWy2OYPEmk8fxWAz2M5+xpN0jed1ejcUZ5Ba4iu3jEDc5s= =47K2 -----END PGP SIGNATURE-----