As nearly as I can tell, DBMS_CRYPTO is not accessible to any users by default. Even running
GRANT ALL PRIVILEGES TO [some user]
doesn't grant a user privileges to execute functions in it. The only way I've found to grant privileges is to log in as SYSDBA and do so. (Of course, you can then give a user GRANT privileges on the package themselves, but this still requires an initial GRANT using a SYSDBA user, as far as I can tell.)
I don't understand why. Cryptographic algorithms (and functions implementing them) are, by Kerckhoffs' principle, not of any help to an attacker unless they obtain the key. Hash algorithms are equally of no help in discovering the original hashed data, by design. Additionally, if an attacker gains access enough to the database to execute such functions, it is likely they can simply fetch or extract the encrypted data and perform an offline attack elsewhere. So I cannot imagine that this was meant to increase security by preventing an attacker from accessing the functions.
I have read the package documentation and the encryption guide:
https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_crypto.htm#ARPLS664 https://docs.oracle.com/cd/E11882_01/network.112/e36292/data_encryption.htm#DBSEG80087 The documentation does not offer any explanation for why that I could spot; it only states that the package belongs to SYS and permissions need to be granted explicitly. The usage guide also doesn't offer any information about the reason for this that I can see; it only mentions that it recommends revoking the default PUBLIC access on the obfuscation toolkit. The recommendation to revoke access to the obfuscation toolkit makes me think that keeping access to DBMS_CRYPTO limited was a deliberate decision. It is possible that I missed or didn't understand the implications of something, of course.
What is the reason for Oracle choosing to and recommending restricted access to this package? Without understanding this, it is difficult for me to make informed decisions about when I
should grant access.
I dont know of a hard-documented reason, but in the *general* case I suspect it reflects a move toward a greater focus on security, and one of the maxims of that is the concept of "least privilege", namely, only ever give someone *just* the amount of privileges they need by default.
Otherwise you end up in this kind of territory.
which if you think back 20-30 years for Oracle - we used do the same - ship the database with default passwords, everything open and easy to use .... and just as easy to hack.
Returning to the specific case of DBMS_CRYPTO, it (might) perhaps go a small way to avoiding someone mounting a brute force attack *in the database* if they encounter some encrypted database columns. They would at least have to syphon all of that data to an external location and then mount a 3rd party decryption.