A solução integrada da Oracle para esse problema não é a criptografia, mas o controle de acesso usando o Database Vault ou o Virtual Private Database para evitar que o DBA ou outros usuários vejam os dados, respectivamente, e Transparent Data Encryption para criptografar os dados em repouso (SO/arquivo nível de criptografia). Isso não apenas impede o DBA de ver os dados, mas também de alterá-los ou excluí-los.

Se você quiser criptografar os valores de dados de qualquer maneira, toda criptografia/descriptografia e gerenciamento de chaves devem ser tratados externamente do banco de dados onde o DBA não terá acesso às chaves de criptografia. Como isso funciona dependerá do design do aplicativo e da escolha da(s) linguagem(ões) de programação. Esteja ciente de que criar uma criptografia robusta e uma arquitetura de gerenciamento de chaves não um exercício banal...

Esteja ciente também de que encapsular o código-fonte PL/SQL é apenas ofuscação do código e não da criptografia. Pode ser facilmente revertida usando qualquer número de sites existentes ou procedimentos armazenados internos. Um verdadeiro DBA também teria o execute any procedure privilégio ou ser capaz de conceder a si mesmo permissão explícita para executar qualquer função de descriptografia e nem mesmo ter que se preocupar com qual era a chave (apenas o Database Vault poderia impedir isso).

Transmitir a chave para a função como uma entrada em vez de incorporá-la diretamente no código também seria problemático, pois o DBA pode ver seu SQL de várias maneiras. Quando transmitida por meio de consulta SQL, a chave também pode ser exposta em relatórios ADDM, arquivos de rastreamento de banco de dados ou trilha de auditoria.

Não há não maneira segura de lidar com a criptografia como você está descrevendo com PL/SQL que também protege os dados do DBA.