Data storage encryption – Part 2: how to use symmetric and asymmetric encryption in practice

Part 2 of 3 – Practical application

In Part 1 of this series, we discussed the context, basic encryption concepts and where it appears in data storage. Now we move into practice: how to use symmetric and asymmetric encryption for data at rest in a strategic way.

1. When to use symmetric encryption for data at rest

Symmetric encryption is the natural choice to protect large volumes of data in day-to-day operations, because it offers strong security with excellent performance. Typical scenarios include:

• Disk and volume encryption: database servers, application servers, workstations with sensitive data;
• Transparent data encryption (TDE) in databases;
• Protection of files, reports and backups stored locally or in the cloud;
• Encryption of specific table fields, such as personal identifiers, financial data or trade secrets.

In almost all these cases, algorithms such as AES with 128- or 256-bit keys, in modern modes (such as GCM), are considered the market standard.

2. Conceptual example: encrypting sensitive database fields

Imagine a customers table with the following fields:

• id
• name
• email
• national_id
• phone

Your goal is to reduce the impact of a breach by protecting national_id and phone. A common approach would be:

1. Dedicated key: the application obtains from a secrets vault a symmetric key specifically for personal data;
2. Before writing:
   • it receives the national ID in cleartext;
   • it encrypts the value with the symmetric key, using an authenticated mode (for example, AES-GCM);
   • it stores the encrypted result (for example, Base64-encoded) in the national_id field;
3. On read:
   • it fetches the encrypted value from the database;
   • it retrieves the symmetric key with proper permissions;
   • it decrypts the field in the application and only then displays the data to authorised users.

This way, the national ID appears in cleartext only briefly in backend memory, reducing exposure and the impact in case of unauthorised database access.

2.1 Points of attention for symmetric encryption

• Do not reinvent the wheel: use well-established libraries instead of trying to create your own algorithm;
• IVs (initialisation vectors): avoid reusing IVs in modes that require uniqueness (such as GCM and CTR);
• Plan queries: if you need to search records by national ID, for example, direct encryption may make indexing and search harder. A common alternative is to combine hash + salt for exact lookups and encryption for storage;
• Key management: the security of the solution depends directly on how the key is stored and used – the central topic in Part 3.

3. The role of asymmetric encryption in data storage

Asymmetric encryption is generally not used to encrypt large volumes of data at rest because it is more computationally expensive. However, it is crucial in two strategic roles:

3.1 Protecting symmetric keys (envelope encryption)

A widely adopted pattern is envelope encryption:

1. Data is encrypted with a data key (a symmetric key);
2. This data key is then encrypted with the public key of an asymmetric key pair;
3. The corresponding private key is kept highly protected, for example in a KMS (Key Management Service) or HSM;
4. When the application needs access to the data:
   • it sends the encrypted data key to the secure service;
   • the service decrypts the data key using the private key;
   • the application uses the data key in memory to decrypt the data and discards the key soon afterwards.

With this approach, even if someone copies the database and associated files, they still do not have the private key required to unlock the data keys.

3.2 Digital signatures for logs and backups

Another important use of asymmetric cryptography is digitally signing critical artefacts, such as:

• database backups;
• audit logs and access trails;
• sensitive files exchanged between systems.

By signing this data, you can verify whether there has been unauthorised modification. This is especially useful in audits, security incident investigations and integrity assurance for regulators.

4. Combining symmetric and asymmetric encryption in the same architecture

The real strength of encryption in storage appears when you combine both approaches. A typical design looks like this:

1. Data at rest (disks, databases, files, backups) encrypted with symmetric keys;
2. These symmetric keys:
   • are protected by an asymmetric infrastructure (KMS/HSM/PKI);
   • have a clearly defined scope (per environment, system or data type);
   • are rotated regularly.
3. Key usage is controlled and audited:
   • who is allowed to request decryption;
   • from where, when and in which context;
   • with detailed records of every operation.

This is the model you will find, for example, in major cloud providers and in more mature enterprise architectures.

5. Wrapping up Part 2: what comes next?

In this second part, we have seen how to apply symmetric and asymmetric encryption to data at rest in practice, with examples and an architecture design that combines both approaches.

In Part 3, we will address the critical foundation that underpins everything: key management, good governance practices, alignment with LGPD/GDPR and a checklist to start or evolve your encryption strategy.