<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2826169&amp;fmt=gif">
Start  trial

    Start trial

      Information Technology security is getting more complex each time I visit the subject. This just makes it harder for Security Specialists, whose role is to ensure that all potential threats are mitigated across the myriad of hardware, firmware, and software that make up a modern Enterprise Infrastructure. 

      Complexities of security

      The flexibility that modern companies are affording employees to maximize productivity, significantly increases the risk of IP theft, identity theft, information theft and information sabotage. This entails additional risks for the information that they store across their systems, which is one of their most important assets. While databases provide authentication and authorization to control access to the information within via APIs, the responsibility to protect actual physical files containing the data is often left to another department or even distributed across multiple teams.

      It is prudent for database teams to take some ownership for securing physical database files. Encryption of information on disk is a worthwhile consideration to improve security.

      Fujitsu Enterprise Postgres provides Transparent Data Encryption, which supports not only the encryption of the files containing relations, but also logs, backups, and data exports. The method is so named because encryption/decryption of data written to and read from disk is transparent to the user.

      There are encryption options available in the community version of PostgreSQL such as one-way encryption using the pgcrypto module and using a separate tool outside of the database to encrypt data written to disk, but these won’t be discussed in this post, especially since my colleague Vaishnavi wrote a post with an overview of pgcrypto recently.


      Encryption is not usually the first solution that comes to mind when securing a system and its data. Usually, when we think about security, our first goal is to prevent access to those that we don’t know, and secondly to control access of those we do know. Encryption doesn’t prevent access to the physical information, it only denies access to the content — that is, being able to read it.

      Transparent Data Encryption

      The Fujitsu Enterprise Postgres implementation conforms to the Advanced Encryption Standard (AES), which is a standard for a symmetric block cipher. Also known as Rijndael, this specification for the encryption of electronic data was established by the U.S. National Institute of Standards and Technology in 2001. It was adopted by the U.S government in 2002 to protect classified information and is implemented throughout the world to protect sensitive data.

      A block cipher applies a cryptographic key and algorithm to a block of data at a time rather than one bit at a time as used in the stream cipher method.
      The implementation does not impose any increase in the size of tables, indexes or logs, and only a small 5% overhead in performance of data access times to allow for the encryption and decryption of data.

      Why is the overhead so small?

      Fujitsu Enterprise Postgres coded Transparent Data Encryption using the Advanced Encryption Set - New Instructions (AES-NI) instruction set, which utilizes AES-NI support built into the processor. Both Intel and AMD have a range of processors that provide this feature. If you plan on using any form of encryption in your processing, it is worth ensuring that your processor is capable of this feature. Tests have shown performance increases in the range of 4 to 6 times faster than with no AES-NI support.

      How to apply Transparent Data Encryption

      To implement automatic encryption, simply follow the steps below.

      1. Edit the Postgres configuration file postgresql.conf and update the settings below:
        keystore_location: It tells the database where to store the encryption key.
        tablespace_encryption_algorithm: It specifies the type of encryption you want to use — in this example we are setting it to AES256 (Advanced Encryption Standard 256-bit).
      1. Execute the SQL function pgx_set_master_key with a passphrase of your choice to create the master key —- in this example we are using safedata. This will create the file keystore.ks in the location specified in the previous step (see the inset image below).
      1. Restart the server so that it can reflect the new settings in postgresql.conf — in this example I included the option --keystore-passphrase to the command, to tell Fujitsu Enterprise Postgres to open the keystore upon restart.
      1. Create a tablespace (I’ve called it tbsencrypt) and specify its physical location.

      And that is all — data written to and associated with this tablespace from now on will be encrypted: table data, indexes, temp files, WAL, backups, and archive logs.

      What if someone gains access to your environment? 

      With an encrypted tablespace, even if a hacker gains access to your system and manages to access the files that store your data, it will be encrypted. In non-encrypted environments, the data would be laid bare.


      As I previously mentioned, TDE doesn’t stop hackers getting the data, it just stops them from being able to see the content. So how safe is it? Can it be decrypted?

      Brute force attacks against the data are pretty much the only way of dealing with this type of encrypted data by a hacker. This is where the attacker will systematically test every possible combination of key until they succeed.


      Therefore, the solution is to make the number of possible combinations as large as possible — this is done by increasing the key length.

      You can see from the figure below that an 8-bit encryption key only allows for 256 combinations. While many industries feel that 128-bit encryption is adequate, FEP also provides 256-bit encryption giving a massive combination of potential keys.

      Key size Number of possible
      1-bit 2
      8-bit 256
      16-bit 65,536
      64-bit 1.8 x 1019
      128-bit*† 3.4 x 1038
      192-bit* 6.2 x 1057
      256-bit*† 1.1 x 1077

      * Supported by AES  Supported by Fujitsu Enterprise Postgres

      Even with the processing power of today’s super computers, the amount of time required to process the number of combinations for 128-bit encryption is greater than the age of the earth. I’m not a security expert, but I would certainly consider a multiple front approach to securing my data.

      How PostgreSQL stores your table data

      In this post, I showed how an encrypted data file would look like to somebody that had access to it. But to know which data file stores the content of which table, some basic knowledge of how Postgres organizes information in files and directories is required — that will be the subject of my next post "A quick look at how PostgreSQL stores your table data in files and directories".

      You can subscribe for notifications on new blog posts by filling the form on the right side of this page.

      Banner: Download the Transparent Data Encryption white paper


      Topics: PostgreSQL, Database security, Fujitsu Enterprise Postgres, Transparent Data Encryption

      Receive our blog

      Search by topic

      see all >

      Read our latest blogs

      Read our most recent articles regarding all aspects of PostgreSQL and Fujitsu Enterprise Postgres.

      Receive our blog

      Fill the form to receive notifications of future posts

      Search by topic

      see all >