This is a interesting problem.

Perhaps, this is also a way to put a minor level of security onto the
database without alot of work.

If the connect/create api, included the passing of a key value (128 bit
or maybe as long as the page size - size to be figured out once all
things are considered) AND all transmissions/storage in the database
used the key as a basic XOR on operations/data, we would have a very
basic encryption by obscurity mechinism in place that would cover over
the wire data transmission as well.

Only those applications that have the key encoded in them could connect
to the database, even if they had a proper users name and password.

Anyone trying to look at the data via a binary editor would need to have
the key and know where the data starts and stops within the structure
(ie, a smallint would only use the first two bytes of the key, while a
char(16) would use a full 16 bytes of a 128 bit key)

The only real method of decrypting such a system would be to try a brute
force attack on the database or guess the key.

Since the system is only performing a simple XOR operation, no complex
encryption/decryption routines need be implemented in the server, only a
encode/decode layer which prepares the data.

This is far from perfect, but may cover all the points asked for by
people on the list.

best regards

Dalton


Jim Starkey wrote:

>
> At 08:37 AM 5/30/00 -0600, Tim Uckun wrote:
> >
> >There ought to exists a mechanism such that only the application I have
> >written should have any access to the data and schema.
> >
> >
> >That's it. The file ought to be utterly useless to anything and anybody
> >other then my application. My application will interact with the data and
> >show the results to my customer if, where, when and how I want.
>
> Is the application restricted to the native InterBase API? Or must
> the solution work with ODBC, JDBC, BDE, etc? Does there need to
> be an escape for third party report writers, etc? Do you need
> to be able to back it up?
>
> What threats should the mechanism reasonable protect against? A
> well meaning but misadvised user? An application program wanting
> to write an extension? A competing developer?
>
> Jim Starkey
>
> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959697861/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com