On Tue, 8 Aug 2006, Daniel Carosone wrote:
> On Mon, Aug 07, 2006 at 10:29:49AM +0100, Stephen Borrill wrote:
>> I'm using des_ncbc_encrypt() as it seems to be the best compromise of
>> speed, ease of use and non-trivial encryption.
>
> Others have philosophised about the use of alternate ciphers, while
> making assumptions about your criteria for this compromise.  I have
> nothing specific to add to the cipher choice debate, except to note
> that perhaps it is necessary to offer this choice in the
> implementation -- or to be very clear and specific about the intended
> uses of the system that justify your choices.

I've now rewritten my patches after a discussion with Greg Troxel. I've 
reverted the vndio struct and instead added a VNDIOCSETCIPHER ioctl. I've 
added a framework for multiple ciphers (but only added DES and 3DES so 
far) and implemented this in vnd, vnconfig and vndcompress.

> I'm more concerned with how the cipher (whichever cipher) is used; for
> example, do you provide protection against block relocation or
> substitution, such as cgd does with its encblkno IV generation?  What
> is a block or cbc run, in your post-compression context?

Well, this is going to be an issue as we need random access to the blocks 
(which by default are 64k uncompressed). I'm therefore resetting the IV 
every time a block is uncompressed and so treating each block completely 
independently.

> Aside from these narrower issues, I would also strongly endorse the
> suggestion of splittng out the compression mechanisms from vnd, into a
> separate block device that could be stacked as needed. This would be a
> preferable overall approach, especially if you're after something for
> adoption into the main codebase rather than just a quick solution to a
> thorny local problem.

(a point also made by Bill)

Yes, this is true, but this is outside my area of knowledge at this point.
The existing compressed vnd code has been accepted and to add encryption 
to this is a much smaller change (at its simplest it boils down to one 
line in between the compressed block being read in and being handed off to 
decompression). It's not adding bloat (it doesn't require the crypto 
framework as DES is included by default and there's a nice fast i386 
assembler implementation).

> Otherwise, if you're really only after something acceptable for the
> narrow specifics of your particular scenario, it seems like you're
> most of the way there already - well done.

My requirements are distributing an embedded OS in flash with various 
modules as separate compressed vnds. So yes, my particular scenario is 
quite specific and for my purposes, my code works well.

I have no problems if this code is considered to be too specific or too 
basic for inclusion. Just the discussion around it is interesting. I'll do 
another day's polishing and put the patches up for them to live or 
die on their own merit.

-- 
Stephen