My understand is you can't use table or tablespace encryption because you not only want the data encrypted in the file, but also when retrieved by SQL for everyone except those who have the privilege to see it. With this in mind, you need to encrypt it manually.
This sounds like a job for DBMS_CRYPTO:http://www.oracle-base.com/articles/10g ... bms_crypto
You don't actually encrypt whole columns with this method, just individual values, so you must manually encrypt ever value before you insert it, and decrypt every value when you select it. You could do the encryption using triggers, but the best method in my opinion is to only allow inserts via a PL/SQL API and do all the work in that API.
Likewise, when you query the table, you will have to decrypt every value, so this is better done via an API also.
As you point out, key management is the killer. Why? Because if you store the key in the database, then the DBAs have access to it and can therefore decrypt the data. If it is not in the database, then someone needs to enter it when they query the data in this table (so the data can be decrypted). Depending on the usage of the data, this can be a problem, since several people my have to memorize the key, and if they forget it, the data is lost. No going back!
The column definitions also present a problem, because every column in the table must be defined as RAW, so you will need to store an indicator of the original type of the data, so you know how to convert it back, otherwise you will not know whether it is a string, number or date etc.
These issues require some thought on your part before you can start an implementation. This is why some people just pay for data vault.