>I didn't really read the original requirement, but I recall it being
>something along the lines of hiding a database schema. The basic principle
>is this: If software in the user's environment can decrypt the schema for
>use, and the user can examine state of the software while it is running, the
>user can acquire the key and then acquire the information in the clear. As
>Jim Starkey has pointed out, it might be obscure enough, but it isn't
>security.

We keep going around on this. Surely either there is a solution or a
compromise someplace.
Presuming that the need to keep data secure is a legitimate one we ought to
work towards a solution. everything you say is absolutely 100% right but
that does not mean that we should do nothing and leave everything unencrypted.

Take for example access (please!). You can "lock" an access database with a
password. If your application "knows" the password then you can open it and
start working if not then you have to expend effort into cracking the
password. Once you are in there is also a user level permission system
where another layer of authentication takes place. Is this perfect? Of
course not. But it is a reasonable effort at securing your data. That's all
anybody is asking for here. Not perfect just a reasonable degree of Due
Diligence.

Surely the combined brainpower of the listserve can find a solution.

----------------------------------------------
Tim Uckun
Mobile Intelligence Unit.
----------------------------------------------
"There are some who call me TIM?"
----------------------------------------------