> > You can write an UDF that makes the encryption/decryption
> > of the data.
>
> I've often heard this sort of suggestion... but I object to
> it being called encryption. This sort of thing can obscure
> the data to stop amateurs from reading it, it is not suitable
> for use where strong security is a requirement.
>
> I am not going to try and offer detailed explanations here, it
> is not my area of expertise either, just a long time interest.
> The sort of "encryption" offered by UDF could soon be broken
> by the patterns produced over many rows of data... if it came
> to that, probably easier to break the system via it's key
> management (because most UDF suggestions dont have any).
>
> To reduce pattern problems the encryption would have to be
> implemented at a much lower level - but this would still not
> avoid the hints offered by index and relationship data. The
> ability to extract identity information (for example) from
> surrounding detail is something well studied by security
> experts.
>
> The trick with encryption is not to write something that you
> cannot break, it is to write something that someone smarter
> than you cannot break (in any reasonable time).
>
> --
> Geoff Worboys
> Telesis Computing

Hi, Geoff

If the database is on a remote server, public and private RSA/3DES/AES keys can be stored
in the same folder where UDF resides (not in the database) and when the udf is loaded,
keys are loaded too. If remote access to the server files is really secure, no one will be
able to get the keys. Also if you know one key and you discover how to get the other part,
RSA will pay you too much money beacuse the security risk. This is like you store plain
text passwords in PHP/ASP files in order to access to a database, but nobody can see php
code.

For the other side, if the database is stored in the same computer that the application is
running or in a "local server" with easy access to it, simply there is NO security method
that will work because any people can hack the UDF and/or make some reverse engineering
stuff.

Best regards,
Mauro H. Leggieri