>> willy.bojit@ btinternet. com wrote:

> >

> > Back on topic, but on another tack, MS SqlServer allows for

> encryption of stored procedure statements. From a developer's

> perpective, this is a great benefit and one which I would love to see

> in Firebird. It is in fact one of only two reasons where I prefer

> SQLServer. There are of course other reasons for where I prefer

> Firebird.

>

> That kind of encryption is much easier in closed source

> software. Where do you put the key and how do you keep

> someone from finding it if they can build a debugging

> version of Firebird?


>As you know, encryption without physical server security is not worth anything.

>Under Windows it should be possible to store a Certificate in the Machine Certificate Store (only Admin accessible), with the certificate name and public key stored within the database header.

>When the database was opened the engine could validate the private key against the stored certificate (located by name). Once validated, the certificate would be used to encrypt/decode the non-header pages.

>A debugging build of the engine would only be useful if the version was installed on the protected server. Which would sort of defeat the whole purpose of an encrypted database.

Possibly the wrong can of worms, but...In SqlServer it is called "encryption" but may in fact be as simple as a flag. Whatever the mechanics, the outcome is that if set, the procedure "internals" are never, ever visible again to anyone including the creator and sa. Hint: do not set this flag on your development server.

Over and Out
wb