On 02/21/12 01:58, Roberto Waltman wrote:
First, I did the 2nd. (Change location only) I believe I tried the first form also *after* things were already broken, but I'm sure the passphrases were identical: slice_08, slice_18 and slice_28 for each pools 0/1/2. - The '8' to bring the length to the minimal requirement of 8 characters.
A 'zfs key -c' won't work unless a 'zfs key -l' or 'zfs mount' has successfully loaded the key first.
Can you send the 'zpool history slice_2' output so I can see what commands have been run.
( My goal for using encryption was just to obfuscate the contents if, for example, I send a disk out for repair; not to hide anything from the NSA ) Question: I believed the keys generated from a passphrase depend only on the passphrase, and not on how it is provided or where it is stored. Is this a true statement?
Almost, the passphrase case also depends on a hidden property called "salt" that is updated only when you do 'zfs key -c' and was set to a random value at the time the dataset was created.
Did you ever do a send|recv of these filesystems ? There was a bug with send|recv in 151a that has since been fixed that could cause the salt to be zero'd out in some cases.
slice_2/base/bitsavers keysource passphrase,file:///export/home/trouser/passphrases/slice_2_passphrase local
This is the interesting part you have set the keysource explicitly on every leaf dataset - you didn't need to do that it would have been inherited.
What this means is that even though you have the same passphrase for each dataset the actual data encryption key is different because the passphrase value plus the hidden salt property are used together to generated the wrapping key.
-- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
