zfs code - Sep 2007 - expanding the size of a zio during the write pipeline

For the CCM mode of AES the ciphertext is slightly larger than the 
plaintext.  This is because of the built in Message Authentication Code 
(MAC).

At what point in the write pipeline do I need take this into account ? 
Encryption happens after Compression but in the case there there is no 
Compression (either because it is off or the compress state didn''t 
result in smaller datasize) the PSIZE will be larger than the LSIZE (the 
opposite of compression).

I know the additional amount of space I need at the start of the 
zio_write_encrypt() stage (it is actually a hardcoded amount rather than 
a function of the input size).

Do I need to somehow reallocate the block ?

-- 
Darren J Moffat

There are all kinds of problems with this.  It''s not OK to grow the
amount of space used -- that''ll break quotas, reservations, etc.

We should really get together for a comprehensive design review.
When''s the next time you''re going to be in town?

Jeff

On Fri, Sep 14, 2007 at 06:01:05PM +0100, Darren J Moffat
wrote:
> For the CCM mode of AES the ciphertext is slightly larger than the 
> plaintext.  This is because of the built in Message Authentication Code 
> (MAC).
> 
> At what point in the write pipeline do I need take this into account ? 
> Encryption happens after Compression but in the case there there is no 
> Compression (either because it is off or the compress state didn''t
> result in smaller datasize) the PSIZE will be larger than the LSIZE (the 
> opposite of compression).
> 
> I know the additional amount of space I need at the start of the 
> zio_write_encrypt() stage (it is actually a hardcoded amount rather than 
> a function of the input size).
> 
> Do I need to somehow reallocate the block ?
> 
> -- 
> Darren J Moffat
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code

Jeff Bonwick wrote:
> There are all kinds of problems with this.  It''s not OK to grow
the
> amount of space used -- that''ll break quotas, reservations, etc.
Okay so we can''t us AES in CCM mode then.  That means that the only 
option will be modes of AES that don''t expand.  For now that means we 
will have to use AES_CBC (which is fine because that is already working!).

One possibility for using AES in CCM mode is to put the 16 byte MAC data 
"elsewhere" I''ll look for some possibilities - one such
possibility is
using that as the checksum instead (but that will mean key material must 
be present to do a resilver/scrub).
> We should really get together for a comprehensive design review.
> When''s the next time you''re going to be in town?
November 12th - 15th I''ll be in MPK.

-- 
Darren J Moffat