I see that many relational database systems offer asymmetric (private/public key) cryptography functions. For example, PostgreSQL offers the pgcrypto module, which supports OpenPGP (RFC 4880) encryption. Given that access to an RDBMS and a specific database is typically protected and restricted, I cannot see the usefulness of this functionality. I appreciate that symmetric encryption of database fields guards their confidentiality, if the database leaks without the corresponding keys (which can presumably exist only transiently in the application server's memory). However, I fail to see what asymmetric cryptography can add. Some scenarios I can think of are the following.

  • Have one database client write data with the public key, and another one, running in a more secure environment, read and process data using the private key.
  • Store data that arrives to the application server already encrypted using the employed public key and exactly the same encryption method.

None of the two uses cases seems particularly compelling to me. Am I missing something? How are database fields encrypted with asymmetric cryptography used in practice, and what is the underlying threat model?

1 Answer 1


Suppose your web application needs to store your users' credit card information for automated recurring billing purposes. For PCI compliance, you might decide to offload the the storage of the credit card information to a service like Authorize.Net that stores and tokenizes the credit card information in a PCI-compliant way.

However, you don't want to be locked-in to using Authorize.Net forever - you want to be able to migrate to another vendor if things go south with Authorize.Net. But, you've seen from posts like this that Authorize.Net does not make it easy for you to export your users' credit card information from their system.

So, you decide that it's best to encrypt and store the credit card information in your own database, in addition to storing the information in Authorize.Net. Asymmetric cryptography is ideal for this use case - the data is encrypted on the server using the public key, and the private key is stored offline. This way, you have the ability to decrypt the credit card information if you ever need to (using the private key) - but if the server is breached by an attacker, he has no way of decrypting the credit card information (because the private key not stored on the server).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .