At 06:51 AM 5/30/00 -0400, Doug Chamberlin wrote:

>>that know what they are doing. The 'walk and chew gum' test?
>
>Sorry, folks, but I've had just about enough of this purist nonsense. The
>above comment says that if Interbase was to have an encryption scheme built
>in which is not absolutely secure in that it can be broken with some effort
>that it would be "useless". The next paragraph says that someone might
>actually depend on this encryption and if they do they clearly will not
>know what they are doing.
>

Going back to the beginning, I think we have established two things.
First, there is a perceived problem. Second, encryption isn't the
answer.

There are lots of ways to solve most problems, but only if the
problem is well understood. So, once again, could somebody make
a stab at a clear problem definition. Not a prospective solution --
just the problem.

If the problem is just hiding the data, a solution could be
a mechanism to take part of the database offline, either in a
separate self describing file or just marked inaccessible. A
sanctioned application program could do something to activate
the offline piece when it needed access. Or, if it is in
a separate file, decrypt it before attaching and re-encrypt
it at end.

Or maybe a simple scheme to XOR a pattern across a page before
writing and after reading, with the pattern passed in as an
attach parameter (not secure, but it does get the job done).

Maybe a beef up of the external file mechanism would suffice...

If the data is numeric, maybe nothing is needed. Compressed
binary data is pretty close to gobbledy-gook.

Maybe something fancier than run length encoding would provide
the obscurity and give better compression to boot (the current
scheme was chosen to be kind to the slow computers we had in
1984). Ever look at a zip file in an editor?

Hey, guys, ideas are cheap. The hard part is figuring out the
boundaries of the problem.

Jim Starkey