where can I find about the pl/sql encryption toolkit

[bberg@rtnyc.com]

I haven't heard much about it, but we are looking for ways to encrypt the stored data, without a lot of performance impact.

Kinda like how credit card numbers are encrypted in a database, we want to do that to some columns... however these columns WOULD be used in a WHERE clause, and the unencrypted data is what is needed.

Any ideas?


thanks.

[tompk]

Here is the answer from metalink.



8.1.6, provides a package for this in DBMS_OBFUSCATION_TOOLKIT package. However, there have been problems reported with this. Protegrity provides a "turn-key solution" whereas this is administrative intensive. From the Oracle 8.1.6 Application Development guide,

"For applications dealing with this highly sensitive data, Oracle provides the DBMS_OBFUSCATION_TOOLKIT PL/SQL package to encrypt and decrypt data, including string inputs and raw inputs. The function is limited to selected algorithms, such as the Data Encryption Standard (DES). Developers may not plug in their own encryption algorithms, and the key length is also fixed. The function prohibits making multiple passes of encryption; that is, you cannot nest encryption calls, thereby encrypting an encrypted value. These restrictions are required by U.S. laws governing the export of cryptographic products.

The cryptographic functions provide encrypt and decrypt services only and do not provide any built-in key management services (such as automatic key recovery). Developers using the package must handle key storage programmatically. For example, encryption keys could be stored apart from the database if the intention is to prevent the DBA from seeing encrypted data.

Development Considerations

In applications using cryptography, encryption must not interfere with other access controls. That is, it must not prevent users from accessing an object they are otherwise privileged to access. Otherwise, their ability to perform their jobs is impaired. For example, a user who has SELECT privilege on EMP should not be limited by the encryption mechanism from seeing all the data he is otherwise privileged to see. There is little benefit to encrypting part of a table with one key and part of a table with another key if users need to see all encrypted data in the table; it merely adds to the overhead of decrypting data before users can read it.

Encrypting indexed data is not supported.

Prudent security practice dictates periodically changing an encryption key to mitigate the threat of a compromised key. Changing the key requires that the encrypted object (or objects) be decrypted and reencrypted using the new key or keys. This process may be time-consuming and would probably have to be done when the data is not being accessed. "


One of the 3rd party partners seems to provide a good solution on this, Protegrity. Check for more information at [url]http://www.protegrity.com.[/url]