create context mycontext using mypackage accessed globally;

create or replace mypackage is 
...
procedure set_key(p_key in varchar2) is 
...
dbms_session.set_context(
  namespace => 'mycontext', 
  attribute => 'key', 
  value     => p_key, 
  username  => 'MYUSER');
...

exec mypackage.set_key('top-secret');

select sys_context('mycontext', 'key') from dual;

select sys_context('mycontext', 'key') from dual;

select * from global_context;

there is not, besides, the key would just be in memory - visible to anyone that could attach to the SGA.

anyone would be able to read out the setting of the context from v$sql. it would/could be in your AWR/ASH repository too (on disk).

key management is really really really hard. really hard. really really really hard.

what happens when you need to re-key your data? when your key has been compromised - or you just need to because the rules governing encryption (government rules, industry rules) say you have to?

and what happens when you do re-key your data. how do you preserve the key history so your backups can actually be used if/when they need to be used?

I suppose you could revoke select on global_context from public (after consulting support). but even then, it could show up on disk (in trace files, in DBA_ views).


but honestly, if you do key management yourself, it needs be done outside of the database - as well as the encrypt/decrypt operations, if you send the key to the database, either as a literal or as a bind, it will be visible to various people and may well be recorded in the dictionary - exposing it to compromise in the event of the theft of your database.

and if you do it outside the database - you have to be willing to do it all - managing the key history, somehow integrating that in with backup and recovery, implementing re-keying of data, and so on.


(and don't forget you can only store encrypted data in RAW() fields - never in varchar2!!! If you store in varchar2, you have to store the HEX representation (A-F, 0-9) and never the encrypted data straight. If you attempt to, if you do not use RAW or a varchar2 field twice as big as the raw with HEX - you will totally corrupt your data with characterset conversions. yet another thing to worry about when you go down the "do it yourself" route.