Date: Sun, 10 Jun 2012 00:36:11 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key Message-ID: <20120610003611.23cba4c7@gumby.homeunix.com> In-Reply-To: <4FD3B8D5.7030906@saltant.com> References: <4FD3B8D5.7030906@saltant.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 09 Jun 2012 16:57:57 -0400 John W. O'Brien wrote: > 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). I think it's fixed at 512 bits and -l determines the key size of the actual encryption algorithm. > 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. I thought that the IV came from a hash that includes the offset, but I'm not sure. > > 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? IMO this is far too much information for the man page or handbook - it might be turned into an article though. What I think is important is that the user understands that the actual encryption derives from a fixed master key and there are two encrypted copies of this, each encrypted with one of the user keys. The above is important to understand because it removes a lot of confusion about what the user keys do and what happens when you change passphrase. It's important to know that changing a compromised user key is ineffective if the metadata has also been compromised. I don't see anything else helps to understand how to use geli, it just buries the useful bit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120610003611.23cba4c7>