> I'm absolutely not an expert on this matter, but I would give
> an example. Ex Turbopower FlashFiler client/server database
> can make encrypted tables on demand. You, the developer,
> decide what encryption method to use (SHA, DES, triple DES
> and many more well known and strong methods,

...

There are several good encryption algorithms to choose from for
this sort of thing.

The problem for metadata data protection is not encryption, the
problem is key management.

> you, the developer, decide the encryption key before compiling
> FlashFiler code, so it is reasonable that only you know the key
> that you have chosen.

So where is the key?

If the key is compiled into the FlashFiler code then at best you
have only some security by obscurity. You may as well only use
a simple XOR algorithm, using strong encryption algorithms is
a waste of time and resources.

> Add to this scenario an application protected with one of the
> possible software protection systems, possibly bound to that
> particular machine and maybe you'll have a system that will be
> not so easy to crack since the application copied in full onto
> another machine won't work at all

Until I use a copy of the program compiled without this
protection - this is an open source product after all.

> and the database file taken by itself will be unreadable
> outside of that machine since only you know the key with which
> the database source code has been encrypted and having the
> possibility to recompile the database source code is hopeless
> for a cracker since he doesn't know the key that might be very
> hard and time consuming to guess, depending on the encryption
> system chosen.

The original query was trying to protect metadata from
legitimate users of the system. For such users to access the
database the server must be able to read the metadata. For
the server to read the metadata it must be able to decrypt it.
To be able to decrypt the data it must have the key. To get
the key it must be provided from somewhere. See my original
post for the options available - and their impracticality.


...

> sometimes it's not that important to
> protect the metadata, but rather the data contained into
> the database.

In this particular statement we agree. Protecting metadata
from legitimate users of the database is not something that
is ever going to work very well. Providing additional data
protection is something that can be useful for servers that
are located in less secure environments - sometimes even on
laptops.

What we disagree about is how such encryption should be
provided. I really dont think that FB is the place to try
and perform such work. There are other products (as already
listed as examples that I know and have used: PGPDisk, Jetico
BestCrypt) that let a user construct encrypted volumes.
Locate the database on such volumes and you have the security
you need.

Security is rarely about protecting only one thing (such as
a database file). As such an encrypted volume is better than
having FB performing the encryption. A volume lets you store
other things as well, such as word processor documents, email
folders and so on.

Despite the availability of open algorithms, implementation
of encryption is not a simple task. It is very easy to get
it wrong and leave side doors wide open. Much better to have
it done by specialist implementations - implementations that
are very widely tested specifically for their security.

And finally. These encryption solutions already exist, no
need to wait for FB v4 or whatever. Go out and choose the
solution you want and have it working tomorrow!

--
Geoff Worboys
Telesis Computing