> Given the code, it would be next to trivial to pass in an encryption
> key in the database parameter block used in the block read/write
> routines to encrypt the database.

OK.

> Perhaps a VAR might want to do
> that, even given the cpu hit that it's going to cost him.

The argument that encryption will take CPU cycles is just a cost/benefit
issue for the developers/users involved. If they want the functionality,
they have to pay. It shouldn't be a basis for deciding whether or not the
functionality should be supported.

> If the
> VAR makes the change to a private code base and distributes only
> the binaries, he's got a fighting chance that obscurity will prevail
> and his database will be secure from prying eyes (and third party
> tools, of course).

Yes, that's the VAR's decision.

>
> A different question is whether the mainline codebase would support
> that functionality. I would argue that it shouldn't for severals
> reasons. First, on a theoretical basis, it's a joke. Second, on
> a practical basis, a day after the feature is introduced, somebody
> will publish a key retrieval hack to renders the feature completely
> useless.

Yes, I can see the problem, and agree that the mainline code base shouldn't
do that part of the dirty work.

> Security features should be theoretically sound so all we have to
> worry about is the implementation and administration (which is hard
> enough). I don't think we should kit ourselves that additional
> obscurity is going to help.

Don't get me wrong: I'm not advocating "security-thru-obscurity". However, I
still don't feel we're getting any closer to a solution.

-ST