Posted by Martin on 12/09/05 08:23

> High security means at all levels, including physical access. Your bank
> doesn't give you their confidential data on a disk does it? That's why
> they don't need to encrypt it in the database - because they can secure
> and authenticate the access to the data.

You are thinking about databases in their, shall I say,
traditionalcorporate/business application.

Let's say that you develop an application. This application does some work
and needs to allow the user to save it to files. Much like MS Word or
Photoshop let you save files. Now, the application can be best written if
it can use database technology while doing its job. However, the resulting
files need to be encrypted for security reasons. There are many possible
reasons for this. One may be that you don't want your competition to
benefit from your work product and extract data from your files.

The choices, as I see them, are:

1- Create a completely custom file format, re-invent the wheel and roll out
your own db-style code. The file would be encrypted upon storage and
decrypted upon loading.

2- Use some sort of db system that is encryption-capable. Something like
SQL server isn't a possibility because customer machines will not have this
available.

Yes, of course, with enough time and effort almost anything can be cracked.
And, of course, the astute might even be smart enough to dig through memory
for the data. Those I see as extreme cases. I am more interested in the
old "keeping honest people honest" scenario rather than the high-IQ hacker
scenario.

Makes sense?

-Martin

[Back to original message]