zfs crypto discuss - Mar 2007 - per dataset vs per pool

[ I''ve moved this discussion to the opensolaris zfs-crypto project
alias
where it belongs. ]

Nicolas Williams wrote:
> On Mon, Mar 05, 2007 at 11:52:56AM -0800, Jeff Bonwick wrote:
>> Yes.  For that reason, when we implement ZFS on-disk encryption,
>> we''ll have two options: per-dataset and per-pool.  In the
per-pool
>> model, *everything* will be encrypted -- the disk really will look
>> like random noise.  In the per-dataset case, we''ll encrypt
everything
>> but the block pointers.  That way, if you forget the key to a dataset,
>> at least you can still free it and get the blocks back.  From just the
>> block pointers you can''t get user data or file names, but you
can get
>> structural information like distribution of file sizes and birth times.
>> That''s probably not useful in any material sense, btu for the
truly
>> paranoid, pool-wide encryption solves the problem.
> 
> You''d still have to provide integrity protection for the
meta-data,
> i.e., key the ZFS checksum/MAC.
> 
> If you lose the key, how can you validate the meta-data?
> 
> Also, if you MAC-but-don''t-encrypt some meta-data then
you''re giving a
> cryptanalyst more material to play with for attacking the key (which is
> just fine as long as the key is large enough and randomly generated,
> rather than derived from a password).
An AES key derived from a passphrase/password using PKCS#5 should 
probably be okay in this case though, right ?

-- 
Darren J Moffat

On Tue, Mar 06, 2007 at 01:22:24PM +0000, Darren J Moffat
wrote:
> Nicolas Williams wrote:
> >On Mon, Mar 05, 2007 at 11:52:56AM -0800, Jeff Bonwick wrote:
> >>Yes.  For that reason, when we implement ZFS on-disk encryption,
> >>we''ll have two options: per-dataset and per-pool.  In the
per-pool
> >>model, *everything* will be encrypted -- the disk really will look
> >>like random noise.  In the per-dataset case, we''ll encrypt
everything
> >>but the block pointers.  That way, if you forget the key to a
dataset,
> >>at least you can still free it and get the blocks back.  From just
the
> >>block pointers you can''t get user data or file names, but
you can get
> >>structural information like distribution of file sizes and birth
times.
> >>That''s probably not useful in any material sense, btu for
the truly
> >>paranoid, pool-wide encryption solves the problem.
> >
> >You''d still have to provide integrity protection for the
meta-data,
> >i.e., key the ZFS checksum/MAC.
> >
> >If you lose the key, how can you validate the meta-data?
> >
> >Also, if you MAC-but-don''t-encrypt some meta-data then
you''re giving a
> >cryptanalyst more material to play with for attacking the key (which is
> >just fine as long as the key is large enough and randomly generated,
> >rather than derived from a password).
> 
> An AES key derived from a passphrase/password using PKCS#5 should 
> probably be okay in this case though, right ?
I was expecting actual ZFS keys to be generated randomly and stored on
disk encrypted with keys derived from user passwords.  Which is no
stronger than what you suggest, unless they are stored separately from
the pools (which you might want if the threat model assumes attacker
control of pool disks, which it should).

Nico
--