At 06:09 PM 5/25/00 +0200, Steve Tendon wrote:

>> If you assume that a) a bad guy has access to the database file and
>
>
>No, he's probably not that skilled. I know very well that professional
>crackers will get in. I'm concerned about the 99.999% which aren't
>professional crackers, and all those that aren't crackers at all but just
>plain curious. Today the door is wide, wide, wide open...
>
>BTW, I read in IB-Priorities a long reply by Charlie (Caro) about encryption
>plugin support that was there once upon a time. Any comments on that?
>

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. Perhaps a VAR might want to do
that, even given the cpu hit that it's going to cost him. 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).

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.

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.

Jim Starkey