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.
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
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