--GyRA7555PLgSTuth
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> speed, ease of use and non-trivial encryption.=20

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'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?

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.

Doing so side-steps the cipher debate entirely, and corrects the
limitation of the current compression layer which is the underlying
cause of your problem.

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.

> [des_* vs DES_ and openssl headers]

Openssl made a mess of their DES API, and then a messy change to it a
little while ago; I think this is mostly due to that. Since I guess we
don't really expect much new development using DES, the pain has
mostly already been felt. Trying to 'fix' the slightly ugly scar left
behind would just create potential for new errors and maintenance
difficulties with other code (eg, other BSD's).

--
Dan.

--GyRA7555PLgSTuth
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFE170vEAVxvV4N66cRAsWaAKCGfPWMwEbBRqpJx8PdgFsCDPF0MgCcCXLA
IvSprye3FHpjQhmUDG1o2dw=
=BgsC
-----END PGP SIGNATURE-----

--GyRA7555PLgSTuth--