zfs discuss - Jul 2007 - ZFS Crypto Design review: 2007-07-02 through 2007-07-16

All details on how to participate are posted on the review site:

	http://opensolaris.org/os/project/zfs-crypto/design_review/

-- 
Darren J Moffat

Comments:

 - Need references to AES, HMAC, and various cipher modes.

 - The link to the ZFS ondisk format is dead.  I think you want this
   one:

   http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf

 - Is the addition of that one field to the dnode the only ondisk format
   change?

    - The addition to the dnode seems to imply that the dnode itself is
      not encrypted.  A different solution may trivially avoid the bonus
      problem.

    - Did you consider changing blkptr_t instead?  Since the document
      discusses the need for per-block key version identifiers it would
      make sense to put the encrypted/not-encrypted flag in blkptr_t.

      See below.

 - Presumably the authentication tag from an AEAD cipher mode like CCM
   (or the HMAC, when using non-AE cipher modes like CBC) will be stored
   in the blkptr_t instead of the traditional ZFS checksum.

    - Side effect of replacing the ZFS checksum with the cipher''s
      authentication tag: all keys are needed in order to scrub a pool.

      Perhaps you could allow the use of both, a light-weight checksum
      and an authentication tag so that scrubs are possible without
      having data keys available (meta-data keys or cleartext meta-data
      would still be needed).

    - The exact ondisk format changes needed for phase1 should be
      documented, and the implications of future features for the ondisk
      format should be discussed as much as possible (though, obviously,
      we can''t predict the future).

 - Using a master per-pool key neatly solves the problem of how to
   release blocks from encrypted datasets, or so I recall from earlier
   discussions (but maybe that problem is moot?).

   If this is a motivation for per-pool master keys then state it
   explicitly.

 - Separate data and meta-data keys would be useful for zfs send/receive
   as well.

    - Why aren''t separate data and meta-data keys part of phase 1?

      I would think that having this feature would make secure data
      deletion simpler because you need not worry about how to reclaim
      the blocks freed in the process (but I don''t remember how dataset
      destruction works, so perhaps I shouldn''t worry about this at
      all).  If being able to traverse meta-data is important for any
      house-keeping then such a separation should be considered for
      phase 1.

 - Per-block key versioning would, presumably, consume some of the pad
   space in blkptr_t, unless the key version number were associated with
   the birth txg of the block.  I''m not sure if this is the sort of
   comment you would rule out at this stage, but it seems to me that if
   you know that you''ll lay a claim on pad space anywhere sometime in
   the future then now''s the time to give a heads-up about it.

    - But tying the key vno to the birth txg won''t suffice if
you''d have
      separate keys for data and meta-data -- you''d have to know
whether
      a given blkptr_t points to data or meta-data, either from context
      or from a bit in the blkptr_t.

    - Cipher and mode information could be associated with the key, thus
      saving space in blkptr_t and/or dnode_t/dnode_phys_t.

 - What about the ZIL?

 - I don''t think we should assume that crypto HW accelerators are
always
   faster than SW crypto, though as an initial assumption it will do (we
   can always later determine the optimal block/transaction size cut-off
   for each type of HW and implement such a cut-off, for keys that are
   allowed to be unwrapped in core).

 - If zfs send will output cleartext only in phase 1 then how can users
   encrypt that output?  Piping it to ssh is an option, certainly, but
   for longer-term storage something like encrypt(1) would be useful --
   sadly, however, encrypt(1) does not provide integrity protection.

Nico
--

Darren J Moffat wrote:
> All details on how to participate are posted on the review site:
> 
> 	http://opensolaris.org/os/project/zfs-crypto/design_review/
> 
Upgrade from zfs-crypto phase 1 to all later phases should be supported.  If 
this is not possible, please explain why.

How do you plan to encrypt user dataset properties?  This is non-obvious 
given that they are currently mingled with the other properties when stored 
on disk.

You mention a "per-block key version".  In what use scenario will this
be
used?  How much space will this take in the blkptr_t?

"What is encrypted" - please describe this in terms of (A) the zfs
on-disk
format (eg, all bonus buffers and data (level-0) blocks are encrypted) and 
(B) what information is visible to someone without the key (eg, the type and 
size of each file).

Should note that clones will be encrypted *with the same key* as the clone 
origin filesystem.

"Need a way to interact with the user during boot or service restart to get
the master passphrase or token PIN entered." -- this seems nontrivial.  How
do you plan to do it?

What is the difference between the "CCM" and "CBC" modes? 
Why is a new
"HMAC" sha256 checksum algorithm needed?

Presumably the pool "setkey" will be a new pool property?

What is the dn_crypt field in the dnode_phys_t/dnode_t used for?  I
don''t
see anything in your proposal that could use it.

Please describe the on-disk changes needed to store the per-dataset keys.

Why bother with the per-dataset keys, when security is actually accomplished 
with the per-pool key?

Futures discussion:

Secure deletion: this only applies to securely deleting the whole pool, 
right?  You don''t describe any way of securely deleting just a single
dataset.

Timed secure key deletion:  I don''t see how this would work, given that
the
key manager doesn''t have access to the per-dataset key.

Migration: at a minimum, you''ll have to add a -o
<property>=<value> option
to "zfs recv"...

Quoth Darren J Moffat on Mon, Jul 02, 2007 at 05:18:46PM
+0100:
> 	http://opensolaris.org/os/project/zfs-crypto/design_review/
Looks good.  Some questions:

  - Is it correct that the pool key will not be written to disk, but it
    will be kept in memory and used to encrypt and decrypt a ZFS object
    which contains keys for encrypted filesystems in the pool?

  - Do you expect "setkey" to become a zpool subcommand?  Will there
be
    an option to specify the pool key at zpool import time?

  - I wondered if it will be possible to migrate the key for
    a filesystem from the pool file to a hardware keystore in the
    future.  Is that covered by the phase-1-upgrade comment on the
    webpage?


David

On Mon, Jul 02, 2007 at 02:14:06PM -0700, Matthew Ahrens
wrote:
> "Need a way to interact with the user during boot or service restart
to get
> the master passphrase or token PIN entered." -- this seems nontrivial.
How
> do you plan to do it?
I think that''s a reference to SMF work.  Currently there''s no
way to
tell SMF that some service may need to interact with users on the
console -- without this it is possible to open /dev/console and interact
anyways, but SMF will not know to serialize the start of multiple such
services (using dependencies for this is awkward).
> What is the difference between the "CCM" and "CBC"
modes?  Why is a new
> "HMAC" sha256 checksum algorithm needed?
CCM is an Authenticated Encryption (AE) mode (actually, it''s an AEAD
cipher mode -- Authenticated Encryption and Additional Data).

CBC is not an AE cipher mode.

AE cipher modes output ciphertext and a data authentication tag that is
much like a checksum.  The authentication tag is an input on decryption;
decryption outputs cleartext or an error.
> Presumably the pool "setkey" will be a new pool property?
My impression was that it''d be an operation -- a sub-command to the
zpool command.

Nico
--

On Mon, Jul 02, 2007 at 04:06:39PM -0500, Nicolas Williams
wrote:
>       Perhaps you could allow the use of both, a light-weight checksum
>       and an authentication tag so that scrubs are possible without
>       having data keys available (meta-data keys or cleartext meta-data
>       would still be needed).
(Of course, in such a mode the light-weight checksum should be taken
over the ciphertext, and possibly over the authentication tag.)

David Bustos wrote:
> Quoth Darren J Moffat on Mon, Jul 02, 2007 at 05:18:46PM +0100:
>> 	http://opensolaris.org/os/project/zfs-crypto/design_review/
> 
> Looks good.  Some questions:
> 
>   - Is it correct that the pool key will not be written to disk, but it
>     will be kept in memory and used to encrypt and decrypt a ZFS object
>     which contains keys for encrypted filesystems in the pool?
Correct, the pool key is not written to disk by ZFS.  It is either:
1) A passphase manually entered in.
2) Store raw in a file on some other filesystem outside the pool, eg
    on a removable media device.
3) Stored in a PKCS#11 token, which may actually be implemented by 
writing encrypted keys to disk protected by a token PIN (for example the 
OpenSolaris pkcs11_softtoken) or maybe a physical hardware device such 
as the Sun CA-6000.
>   - Do you expect "setkey" to become a zpool subcommand?  Will
there be
>     an option to specify the pool key at zpool import time?
Yes I expect setkey as a subcommand.  I think being able to specify the 
key material at import time is probably needed.
>   - I wondered if it will be possible to migrate the key for
>     a filesystem from the pool file to a hardware keystore in the
>     future.  Is that covered by the phase-1-upgrade comment on the
>     webpage?
For example you have a key in a raw file stored on a USB mass storage 
device and you later put a CA-6000 card into the machine ?

That will be possible.  There will be two separate steps for this, the 
first is to use the pktool(1) command to place the key into the PKCS#11 
accessible hardware keystore.  Then use the zpool setkey command to 
update where the key for the pool is held.

We are still working out the UI for zpool setkey but change of pool key 
from passphrase/file to PKCS#11 will be possible (the opposite maybe 
true from a ZFS view but note that the hardware may restrict removal of 
the key in an unwrapped form).


-- 
Darren J Moffat

Darren J Moffat wrote:
>>   - Do you expect "setkey" to become a zpool subcommand? 
Will there be
>>     an option to specify the pool key at zpool import time?
> 
> Yes I expect setkey as a subcommand.  I think being able to specify the 
> key material at import time is probably needed.
Why should this be a subcommand, rather than a pool property?  What are the 
exact semantics of the proposed subcommand (flags, arguments, etc)?

--matt

Matthew Ahrens wrote:
> Darren J Moffat wrote:
>>>   - Do you expect "setkey" to become a zpool subcommand? 
Will there be
>>>     an option to specify the pool key at zpool import time?
>> Yes I expect setkey as a subcommand.  I think being able to specify the
>> key material at import time is probably needed.
> 
> Why should this be a subcommand, rather than a pool property?  What are the
> exact semantics of the proposed subcommand (flags, arguments, etc)?
A pool property might work, I''ll investigate.

Basically we need a way to indicate if the pool key is one of the following:

1) passphrase to be interactively entered with echo turned off.
2) Description of a PKCS#11 object, see the -T and -K arguments to
the encrypt(1) command for what is likely needed here.
3) path to a file containing a raw key
4) search removable media for a file that has the GUID of the pool as 
its file name (otherwise this is as 3 above).

1 requires interaction with a user.
2 may require interaction to get the token PIN entered if the PKCS#11
object is PIN protected.
3 and 4 don''t require any interaction with a user.

-- 
Darren J Moffat

Quoth Darren J Moffat on Tue, Jul 03, 2007 at 04:58:52PM
+0100:
> David Bustos wrote:
> >Quoth Darren J Moffat on Mon, Jul 02, 2007 at 05:18:46PM +0100:
> >>	http://opensolaris.org/os/project/zfs-crypto/design_review/
...
> >  - I wondered if it will be possible to migrate the key for
> >    a filesystem from the pool file to a hardware keystore in the
> >    future.  Is that covered by the phase-1-upgrade comment on the
> >    webpage?
> 
> For example you have a key in a raw file stored on a USB mass storage 
> device and you later put a CA-6000 card into the machine ?
Actually I meant that I create an encrypted filesystem, the key for
which is randomly generated and encrypted by the pool key, and then
I want to move the filesystem key to another medium, if that becomes
available after phase 1.  Though I suppose that presumes that you''re
considering allowing filesystem keys to be kept outside of the pool,
which I don''t specifically recall from the document.


David

David Bustos wrote:
> Quoth Darren J Moffat on Tue, Jul 03, 2007 at 04:58:52PM +0100:
>> David Bustos wrote:
>>> Quoth Darren J Moffat on Mon, Jul 02, 2007 at 05:18:46PM +0100:
>>>> 	http://opensolaris.org/os/project/zfs-crypto/design_review/
> ...
>>>  - I wondered if it will be possible to migrate the key for
>>>    a filesystem from the pool file to a hardware keystore in the
>>>    future.  Is that covered by the phase-1-upgrade comment on the
>>>    webpage?
>> For example you have a key in a raw file stored on a USB mass storage 
>> device and you later put a CA-6000 card into the machine ?
> 
> Actually I meant that I create an encrypted filesystem, the key for
> which is randomly generated and encrypted by the pool key, and then
> I want to move the filesystem key to another medium, if that becomes
> available after phase 1.  Though I suppose that presumes that
you''re
> considering allowing filesystem keys to be kept outside of the pool,
> which I don''t specifically recall from the document.
For phase 1 the filesystem (dataset) key is held in the pool wrapped 
with the pool key.  The pool wrapping key is the one that can be stored 
in different ways.

For phase 1 we aren''t planning on having filesystem keys that are
either
not wrapped by the pool key or are ephemeral (for encrypted ZVOL used 
for swap).

-- 
Darren J Moffat

Matthew Ahrens wrote:
> Darren J Moffat wrote:
>> All details on how to participate are posted on the review site:
>>
>> 	http://opensolaris.org/os/project/zfs-crypto/design_review/
>>
> 
> Upgrade from zfs-crypto phase 1 to all later phases should be supported. 
If
> this is not possible, please explain why.
Upgrade of the pool should be supported.  It might not be possible to 
upgrade the dataset.  I''d like it to be possible but until we design
the
later phases I can''t commit that a given dataset will be able to be 
migrated to use future zfs-crypto phase features.
> How do you plan to encrypt user dataset properties?  This is non-obvious 
> given that they are currently mingled with the other properties when stored
> on disk.
Hmn, maybe that is ETOOHARD for now and could be dropped.  I''ll keep 
looking since I''d rather they were encrypted if possible.
> You mention a "per-block key version".  In what use scenario will
this be
> used?  How much space will this take in the blkptr_t?
It isn''t used at all just now but is a possibilty to allow online 
rekeying/key change.  How much space it takes up depends on how many 
active keys we would at a time.
> "What is encrypted" - please describe this in terms of (A) the
zfs on-disk
> format (eg, all bonus buffers and data (level-0) blocks are encrypted) and 
> (B) what information is visible to someone without the key (eg, the type
and
> size of each file).
Shall do.
> Should note that clones will be encrypted *with the same key* as the clone 
> origin filesystem.
Shall do.
> "Need a way to interact with the user during boot or service restart
to get
> the master passphrase or token PIN entered." -- this seems nontrivial.
How
> do you plan to do it?
> 
> What is the difference between the "CCM" and "CBC"
modes?  Why is a new
> "HMAC" sha256 checksum algorithm needed?
HMAC-SHA256 is required so that the checksum is keyed.  CBC mode
doesn''t
provide integrity protection and an unkeyed SHA256 can be alterted 
consistently on disk after chaning CBC blocks.
> Presumably the pool "setkey" will be a new pool property?
> 
> What is the dn_crypt field in the dnode_phys_t/dnode_t used for?  I
don''t
> see anything in your proposal that could use it.
> 
> Please describe the on-disk changes needed to store the per-dataset keys.
> 
> Why bother with the per-dataset keys, when security is actually
accomplished
> with the per-pool key?
Different algorithms,mode,keylenght may need different keys.  For 
example an AES-128-CBC key is different to an AES-256-CBC key.  Since we 
allow different datasets to be encrypted using different 
algorithm/mode/keylengths we need different keys for each.

It is also there as a stepping stone for future phases where we will 
need per dataset keys.

-- 
Darren J Moffat

Darren J Moffat wrote:
> Matthew Ahrens wrote:
>> Darren J Moffat wrote:
>> You mention a "per-block key version".  In what use scenario
will this
>> be used?  How much space will this take in the blkptr_t?
> 
> It isn''t used at all just now but is a possibilty to allow online 
> rekeying/key change.  How much space it takes up depends on how many 
> active keys we would at a time.
If it isn''t used now, don''t do it now (unless you have a
reason?).
>> Why bother with the per-dataset keys, when security is actually 
>> accomplished with the per-pool key?
> 
> Different algorithms,mode,keylenght may need different keys.  For 
> example an AES-128-CBC key is different to an AES-256-CBC key.  Since we 
> allow different datasets to be encrypted using different 
> algorithm/mode/keylengths we need different keys for each.
Not being a crypto person, I don''t really see the use scenario for
multiple
algorithms protected by the same key.  Why not just do everything
that''s
sensitive with as strong an algorithm as you might need?  Do you really have 
some data that *needs* to be encrypted with algorithm A and other with 
algorithm B?
> It is also there as a stepping stone for future phases where we will 
> need per dataset keys.
How will that future phase work?

--matt

I''d like to see lots more detail about how specific input parameters to
the encryption modes used are computed, chosen, and/or stored, and I''d
also like to see those details reviewed by Real Cryptographers(tm)
rather than mere cryptographic plumbers like myself.

One concern I have is that I''d like to see the design anticipate the
same sort of design considerations which led to the separation between
nonce and sequence number found in section 8 of RFC3686:

     "Assurance boundaries are very important to implementations that
      will be evaluated against the FIPS Pub 140-1 or FIPS Pub 140-2
      [SECRQMTS].  The assignment of the per-packet counter block value
      needs to be inside the assurance boundary.  Some implementations
      assign the sequence number inside the assurance boundary, but
      others do not.  A sequence number collision does not have the dire
      consequences, but, as described in section 6, a collision in
      counter block values has disastrous consequences."

By analogy I suspect there are benefits from both a security standpoint
and an ease of FIPS evaluation standpoint to pushing the choice of
per-encryption-operation initialization vectors or nonces into a crypto
module rather than leaving the choice in ZFS code.

The obvious place for such a nonce would be in the block pointer.
RFC3686 uses a 64-bit value (and otherwise assumes at most 2^64
cryptoblocks will be encrypted with each AES-CTR key).

On Thu, 2007-07-05 at 09:48 -0700, Matthew Ahrens wrote:
> Darren J Moffat wrote:
> > Matthew Ahrens wrote:
> >> Darren J Moffat wrote:
> >> You mention a "per-block key version".  In what use
scenario will this
> >> be used?  How much space will this take in the blkptr_t?
> > 
> > It isn''t used at all just now but is a possibilty to allow
online
> > rekeying/key change.  How much space it takes up depends on how many 
> > active keys we would at a time.
> 
> If it isn''t used now, don''t do it now (unless you have a
reason?).
I think you could avoid storing a per-block key version if you instead
use the block birth transaction number to index a table of keys (and
assure that all blocks from the same dataset written during the same
transaction are encrypted using the same key). 
> >> Why bother with the per-dataset keys, when security is actually 
> >> accomplished with the per-pool key?
having per-dataset keys or key sequences may make it easier to
incrementally rekey.  Additionally, cryptographers generally recommend
limiting the number of cipherblocks encrypted under each key to perhaps
2**(blocksize/2) cipherblocks.  (I''ve seen this recommendation for both
CBC mode and counter mode; I can explain the rationale for CBC mode if
necessary).
> > Different algorithms,mode,keylenght may need different keys.  For 
> > example an AES-128-CBC key is different to an AES-256-CBC key.  Since
we
> > allow different datasets to be encrypted using different 
> > algorithm/mode/keylengths we need different keys for each.
> 
> Not being a crypto person, I don''t really see the use scenario for
multiple
> algorithms protected by the same key.  Why not just do everything
that''s
> sensitive with as strong an algorithm as you might need?  
So, you''d never want to use the same keying material with multiple
algorithms -- among other things, it gives cryptographers the willies
over the potential for related-key attacks.  

There are a bunch of good reasons for wanting the ability to use
multiple algorithms and multiple keys with each algorithm.

In particular, algorithms occasionally get broken or declared so you
need to be able to change algorithms in addition to changing keys.  If
you can only support one algorithm at a time, or if you never test
multiple algorithms, you may find that you''ve painted yourself in a
corner only when you really need to rekey..
> Do you really have 
> some data that *needs* to be encrypted with algorithm A and other with 
> algorithm B?
Different algorithms have different performance characteristics; AES-256
is more expensive than AES-128.

Also, section 2.3.3 alludes to the potential for "mixed mode"
operation,
where keys near the root of the key hierarchy are handled by slower but
more tamper-resistent hardware, while lower-level keys are handled in
software.  


					- Bill

Bill Sommerfeld wrote:
 > Additionally, cryptographers generally recommend
> limiting the number of cipherblocks encrypted under each key to perhaps
> 2**(blocksize/2) cipherblocks. 
That shouldn''t be a problem; pools support up to around 2^128 bytes of
data;
2^(512/2) blocks is way way way more than that.  (And average blocksizes are 
actually closer to 100k than 512.)

--matt

On Thu, 2007-07-05 at 13:39 -0700, Matthew Ahrens wrote:
> Bill Sommerfeld wrote:
>  > Additionally, cryptographers generally recommend
> > limiting the number of cipherblocks encrypted under each key to
perhaps
> > 2**(blocksize/2) cipherblocks. 
> 
> That shouldn''t be a problem; pools support up to around 2^128
bytes of data;
> 2^(512/2) blocks is way way way more than that.  (And average blocksizes
are
> actually closer to 100k than 512.)
Sorry, all of the above referred to cipherblocks not filesystem blocks
or disk blocks.

The limit is based on the cipher block size -- 128 bits for AES, which
means 2**64 cipherblocks (or 2**68 bytes) per key -- which is well
*under* ZFS design capacity.

"blocks" is horribly overloaded and especially so when you deal with
filesystem encryption.

I''ll try to avoid unqualified use of the word "block" in the
future.

					- Bill

Bill Sommerfeld wrote:
> On Thu, 2007-07-05 at 09:48 -0700, Matthew Ahrens wrote:
>> Darren J Moffat wrote:
>>> Matthew Ahrens wrote:
>>>> Darren J Moffat wrote:
>>>> You mention a "per-block key version".  In what use
scenario will this
>>>> be used?  How much space will this take in the blkptr_t?
>>> It isn''t used at all just now but is a possibilty to allow
online
>>> rekeying/key change.  How much space it takes up depends on how
many
>>> active keys we would at a time.
>> If it isn''t used now, don''t do it now (unless you
have a reason?).
> 
> I think you could avoid storing a per-block key version if you instead
> use the block birth transaction number to index a table of keys (and
> assure that all blocks from the same dataset written during the same
> transaction are encrypted using the same key). 
I considered this but I haven''t been able to work out how we would
bound
the number of keys that would need to be held.  We would need to bound 
this some how so that we didn''t end up with a different key on every 
transaction if someone was too aggressive on applying the newkey (rekey, 
change key whatever) operation.

-- 
Darren J Moffat

Bill Sommerfeld wrote:
> There are a bunch of good reasons for wanting the ability to use
> multiple algorithms and multiple keys with each algorithm.
One of my main motivations for this is to allow us to support AES at 
different key lengths (as well as the different modes).   AES 256 is 
more expensive than AES 128 (192 is pretty much as expensive as 256 in 
some implementations but without the added security).  Some 
organisations have policies that state that data upto a given 
classification can be protected by AES 128 and as the classifiation 
rises you need to move to AES 256.  This fits nicely with Trusted 
Extensions labeling.

I also know that at least two customers I''ve talked to, one US and one 
UK, do wish to have the ability to add an algorithm other than AES for 
some deployments (in both these customer cases I trust that they know 
what they are doing crypto wise!).  They wished to be able to use their 
own algorithm and AES within the same pool.

-- 
Darren J Moffat

Darren J Moffat wrote:
> Bill Sommerfeld wrote:
>> On Thu, 2007-07-05 at 09:48 -0700, Matthew Ahrens wrote:
>>> Darren J Moffat wrote:
>>>> Matthew Ahrens wrote:
>>>>> Darren J Moffat wrote:
>>>>> You mention a "per-block key version".  In what
use scenario will
>>>>> this be used?  How much space will this take in the
blkptr_t?
>>>> It isn''t used at all just now but is a possibilty to
allow online
>>>> rekeying/key change.  How much space it takes up depends on how
many
>>>> active keys we would at a time.
>>> If it isn''t used now, don''t do it now (unless you
have a reason?).
>>
>> I think you could avoid storing a per-block key version if you instead
>> use the block birth transaction number to index a table of keys (and
>> assure that all blocks from the same dataset written during the same
>> transaction are encrypted using the same key). 
> 
> I considered this but I haven''t been able to work out how we would
bound
> the number of keys that would need to be held.  We would need to bound 
> this some how so that we didn''t end up with a different key on
every
> transaction if someone was too aggressive on applying the newkey (rekey, 
> change key whatever) operation.
Don''t you have this problem with any rekeying scheme?  You have to
store
multiple keys, so you will want to make sure it it isn''t too many. 
This
should apply whether you determine which key to use based on birth time, or 
"per-block key version".

--matt

Nicolas Williams wrote:
>  - Presumably the authentication tag from an AEAD cipher mode like CCM
>    (or the HMAC, when using non-AE cipher modes like CBC) will be stored
>    in the blkptr_t instead of the traditional ZFS checksum.
Correct it will not be stored in the traditional ZFS checksum area but 
will be with the data.
>     - Side effect of replacing the ZFS checksum with the cipher''s
>       authentication tag: all keys are needed in order to scrub a pool.
One reason not to do that.  This becomes an advantage for the AES CCM 
modes rather than AES-CBC+HMAC-256 modes and is the reason for storing 
the auth tag from CCM with the data rather than putting it in the normal 
ZFS checksum area.
>  - I don''t think we should assume that crypto HW accelerators are
always
>    faster than SW crypto, though as an initial assumption it will do (we
>    can always later determine the optimal block/transaction size cut-off
>    for each type of HW and implement such a cut-off, for keys that are
>    allowed to be unwrapped in core).
This project makes no such assumption.  Doing stuff like that is the job 
of the crypto framework.  It already knows how to do things like this 
and has (undocumented) tunables for the cut off for when it just isn''t 
worth going to hardware - these tunables are preset to be valid based on 
testing of existing providers.

--
Darren J Moffat

On Mon, Jul 16, 2007 at 11:46:19AM +0100, Darren J Moffat
wrote:
> Nicolas Williams wrote:
> > - Presumably the authentication tag from an AEAD cipher mode like CCM
> >   (or the HMAC, when using non-AE cipher modes like CBC) will be
stored
> >   in the blkptr_t instead of the traditional ZFS checksum.
> 
> Correct it will not be stored in the traditional ZFS checksum area but 
> will be with the data.
Now I''m confused: "with the data" to me says "not in the
blkptr_t," but
I really expected the auth tag to go in the blkptr_t, even if it wasn''t
strictly necessary (since for filesystem integrity the normal checksum
suffices) because it means not changing how much data fits in a given
block.

Nicolas Williams wrote:
> On Mon, Jul 16, 2007 at 11:46:19AM +0100, Darren J Moffat wrote:
>> Nicolas Williams wrote:
>>> - Presumably the authentication tag from an AEAD cipher mode like
CCM
>>>   (or the HMAC, when using non-AE cipher modes like CBC) will be
stored
>>>   in the blkptr_t instead of the traditional ZFS checksum.
>> Correct it will not be stored in the traditional ZFS checksum area but 
>> will be with the data.
> 
> Now I''m confused: "with the data" to me says "not
in the blkptr_t," but
> I really expected the auth tag to go in the blkptr_t, even if it
wasn''t
> strictly necessary (since for filesystem integrity the normal checksum
> suffices) because it means not changing how much data fits in a given
> block.
Since we can have a zio transform that does crypto have a different 
output than input size why not store the auth tag with the data ?

I didn''t want to store the auth tag in the blkptr_t because that makes 
CCM mode special and takes up space in the blkptr_t.

--
Darren J Moffat

On Mon, Jul 16, 2007 at 03:03:17PM +0100, Darren J Moffat
wrote:
> Since we can have a zio transform that does crypto have a different 
> output than input size why not store the auth tag with the data ?
> 
> I didn''t want to store the auth tag in the blkptr_t because that
makes
> CCM mode special and takes up space in the blkptr_t.
That makes sense, and it will make it easier top provide a way to read
the ciphertext and MACs of the file (for encrypted backup/restore).

Will the ubberblock be integrity protected with a keyed MAC?  Will it be
confidentiality protected?