The Oracle database has a feature known as "Native Network Encryption".

It is a protocol described as a 4-step procedure.

  • Step 1 : Negotiate parameters for following steps
  • Step 2 : Exchange a symmetric key via Diffie-Hellman
  • Step 3 : A step described as an "Authentication fold-in"
  • Step 4 : Ciphered communications using the symmetric key obtained as a result of steps 1 and 2. (presumably a concatenation of two sub-keys, though other transformations are possible)

The description of steps 2 and 3 is given in the following brief, taken from here:

Diffie-Hellman Based Key Negotiation

You can use the Diffie-Hellman key negotiation algorithm to secure data in a multiuser environment. Secure key distribution is difficult in a multiuser environment. Oracle Database uses the well known Diffie-Hellman key negotiation algorithm to perform secure key distribution for both encryption and data integrity. When encryption is used to protect the security of encrypted data, keys must be changed frequently to minimize the effects of a compromised key. Accordingly, the Oracle Database key management function changes the session key with every session. You can use Authentication Key Fold-in to defeat a possible third-party attack (historically called the man-in-the-middle attack) on the Diffie-Hellman key negotiation algorithm key negotiation. It strengthens the session key significantly by combining a shared secret, known only to the client and the server, with the original session key negotiated by Diffie-Hellman. The client and the server begin communicating using the session key generated by Diffie-Hellman. When the client authenticates to the server, they establish a shared secret that is only known to both parties. Oracle Database combines the shared secret and the Diffie-Hellman session key to generate a stronger session key designed to defeat a man-in-the-middle attack.

Note: The authentication key fold-in function is an imbedded feature of Oracle Database and requires no configuration by the system or network administrator.

Regarding step 3, there is very little that I could learn. In fact, this paragraph is the only mention of any feature called a "key fold-in" I have been able to find, both in Oracle's documentation and the literature at large.

The only information that is exchanged out-of-band prior to use of this protocol is a rather small quadruplet : (database IP, database name, account user name, account password).

The documentation seems to imply the Diffie-Hellman key exchange phase is not ephemeral and does not provide forward secrecy. But on this, your guess is as good as mine.

I'm inclined to think that this "authentication key fold-in" term is marketing, not cryptography. I'd be happy to be proven wrong if it wasn't.

Is there relevant literature, or documentation, to this feature that I have not found ?

Barring that, what is your best guess on what the feature is ?


1 Answer 1


One possible explanation would be that the "shared secret" is in fact derived from all or part of this quadruplet sent out-of-band : (database IP, database name, account user name, account password).

The password is meant to be secret after all. But given that many databases transition to using Native Network Encryption, and that there is no written advice to change passwords after the transition has been done, I would not consider this a very advisable design decision. Furthermore, Oracle DB imposes no restriction on password strength by default.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.