On Fri, Jan 22, 2010 at 03:08:00AM -0600, Scott Bennett wrote: > > Why is that stored in the last sector of the device, rather than in the > key file? What is the purpose of the key file if not to hold that type of > information?
All geom(4) providers use their last sector to store metadata; it's a design decision. Probably because the first sector(s) are used for boot blocks or filesystem metadata etc. It would have been possible to store the generated key in the user-provided keyfile. But since it is not mandatory to have a keyfile (you can also use just a passphrase), it makes more sense to use the already provided metadata space in the last sector. > >Well, it should be different, otherwise they overwrite the same sector. Ipso > >facto you should nest providers... > > ...unless, of course, the two had been designed to use different parts > of the "last sector" for their own purposes, but also to avoid damaging the > other's data when altering their own. The geom framework was designed to be _extensible_. It was designed so that it would be possible to combine (nest) different types of geom providers, even if those classes (types of providers) didn't even exist when the framework was designed. Trying to shoehorn all metadata for any combination of geom providers into on 512-byte sector would have severely limited the usability of the geom system. In my opinion the solition of using nested providers each using their own last sector for metadata is simple and elegant and avoids that problem rather nicely. As I've been trying to explain, the 'nesting' of geoms is _precisely_ what avoids the whole issue of damaging each others data. I've got the feeling that you do not 'get' that concept, which lead to your problem. Unfortunately, I don't know how to explain it more clearly. > Thanks for the explanation. However, if the key information is stored > in the "last sector" rather than in the key file, then I guess I'm totally > confused about how GELI works. The encryption key is _not_ stored in the last sector. That would be unsafe, like locking your front door and leaving the key in the lock. But a part of the information necessary to create the encryption key is. Your keyfile is just one component of the en- / decryption key to unlock the data. They are not the same. You can use one or more keyfile(s), a passphrase or both. You can also have more than one key; a user key and a 'company' or system key. And geli uses a random component when the encryption key is initially created. The metadata sector is the natural place to store some of that info. This is safe because it is in itself not sufficient to create the en- / decryption key. One also need the keyfile and/or passphase. Personally, I would never use only a keyfile; it is not really secure, especially if you leave that key on another unencrypted partition of the same drive! So-called two-factor authentication (something you have [keyfile] and something you know [passphrase]) is much safer. If you really want to know how geli works, as always with free software, the source code is the ultimate reference. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpOg17AZwPNF.pgp
Description: PGP signature