Data encryption methods: types, algorithms, and choosing protection

Data encryption methods help protect personal information, corporate documents, payments, correspondence, and backups from being read by unauthorized parties. In this article, we will discuss the types of encryption that exist, the differences between symmetric and asymmetric algorithms, where AES, RSA, ECC, and TLS are applied, and how to choose the right approach for a website, application, database, or device.

Encryption does not make a system "invulnerable." It addresses a specific task: turning understandable data into a set of symbols that cannot be read without a key. Therefore, real protection depends not only on the algorithm but also on key management, configurations, updates, access control, and user discipline.

What is data encryption

Data encryption is the process of converting original information, or plaintext, into ciphertext. An algorithm and a cryptographic key are used for the transformation. To return the data to its original form, the correct decryption key is needed.

A simple example: a user sends banking information via a website. If the connection is secured with HTTPS, the browser and server establish an encrypted channel. Even if someone intercepts the traffic, they will see not the card number in plaintext, but a useless set of bytes.

It's important to distinguish encryption from related mechanisms:

• Hashing creates an irreversible fingerprint of data. It's suitable for storing passwords and verifying integrity.
• Encoding changes the format of data but does not protect it. For example, Base64 is easily decoded.
• Obfuscation complicates code or data analysis but does not replace cryptography.
• Signature confirms the authenticity and integrity of the data but does not always hide the content.

In other words, if you need to hide the content, encryption is required. If you need to prove that the data has not been changed, hashes and digital signatures are often used.

Main goals of encryption

Data protection methods are usually chosen based on specific risks. Encryption has several key objectives.

Confidentiality

Confidentiality means that data is only available to those who have permission and a key. This is important for medical records, commercial contracts, personal data, correspondence, and payment information.

Integrity

Encryption itself does not always guarantee that the data has not been altered. Therefore, modern schemes use authenticated encryption, such as AES-GCM or ChaCha20-Poly1305. They simultaneously hide the data and detect tampering.

Authentication

Authentication helps ensure that a participant in the exchange is indeed who they claim to be. In TLS, certificates are used for this purpose, while other systems may use digital signatures and keys.

Non-repudiation

Non-repudiation means that the sender cannot plausibly deny the fact of sending or signing a message. Digital signatures, for instance, based on RSA or ECDSA, are used for this purpose.

Symmetric encryption

Symmetric encryption uses the same secret key for both encryption and decryption. If Alice wants to send a file to Bob, they both must know the shared key. This key cannot be disclosed to third parties.

The main advantage of symmetric algorithms is their high speed. Therefore, they are used for large volumes of data: files, disks, archives, databases, and network traffic after establishing a secured connection.

AES

AES, or Advanced Encryption Standard, is one of the most widely used symmetric algorithms. It is utilized in HTTPS, VPNs, messengers, disk encryption, and corporate systems.

AES supports keys of 128, 192, and 256 bits. In practice, AES-128 is already considered secure for most scenarios, while AES-256 is often chosen for long-term protection and strict regulatory requirements. However, key length is not the only factor; mode of operation and implementation quality are also critical.

Common AES modes include:

• GCM — a modern mode with data authenticity verification. Often used in TLS and APIs.
• CBC — an older mode that requires careful handling of vectors and integrity checks.
• CTR — transforms a block cipher into a stream mode but requires unique counters.
• XTS — used for disk and volume encryption.

For new projects, AES-GCM is often chosen if the environment supports it safely and hardware accelerates AES.

ChaCha20-Poly1305

ChaCha20-Poly1305 is a modern authenticated encryption scheme. It combines the stream cipher ChaCha20 and the Poly1305 authentication code. This option is particularly useful on mobile devices and platforms without hardware acceleration for AES.

ChaCha20-Poly1305 is applied in TLS, VPN protocols, and secure messengers. Its advantage is good performance in software implementation and resistance to several errors common in older modes.

When to use symmetric encryption

Symmetric encryption is chosen when there is a need to quickly secure large volumes of data. Typical scenarios include:

• encrypting files and folders;
• protecting backups;
• encrypting laptop and server disks;
• securing data in databases;
• encrypting network traffic after key exchange;
• protecting secrets in a local application storage.

The main difficulty lies in securely transmitting and storing the key. If the key is stolen, an attacker can decrypt the data.

Asymmetric encryption

Asymmetric encryption uses a pair of keys: a public key and a private key. The public key can be shared with others, while the private key must be kept secret.

If data is encrypted with a public key, it can only be decrypted with the corresponding private key. If a message is signed with a private key, any holder of the public key can verify the signature.

In practice, asymmetric algorithms are rarely used to encrypt large files directly; they are slower than symmetric ones. Therefore, a hybrid scheme is often used: asymmetric cryptography securely transmits or negotiates a symmetric key, while the actual data is encrypted with a fast algorithm like AES or ChaCha20.

RSA

RSA is a classic asymmetric algorithm used for encryption, digital signatures, and key exchange. Its security is based on the difficulty of factoring large numbers.

In modern systems, RSA is typically used with a key length of at least 2048 bits. For long-term protection, keys of 3072 bits and higher are often considered. However, RSA requires the proper padding schemes, such as OAEP for encryption and PSS for signatures. "Raw" RSA without secure padding cannot be used.

ECC

ECC, or elliptic curve cryptography, provides a high level of security with smaller key sizes compared to RSA. This is convenient for mobile devices, IoT, TLS certificates, and resource-constrained systems.

Popular options include ECDH for key exchange and ECDSA for digital signatures. Modern schemes based on Curve25519 and Ed25519 are also widely used.

Diffie-Hellman and ECDH

Diffie-Hellman is a method for agreeing on a shared secret over an open channel. It does not encrypt data directly but helps two parties obtain a common key without explicitly transmitting it.

ECDH is the version using elliptic curves. In TLS, such mechanisms often help create a session key for further symmetric encryption.

An important property of modern configurations is forward secrecy. If a long-term server key is compromised in the future, older recorded sessions should not automatically be exposed. Temporal keys, such as ECDHE, are used for this purpose.

Hashing and encryption: what's the difference?

Hashing is often mentioned alongside encryption, but they are different operations. Encryption must be reversible: data can be decrypted with a key. Hashing is irreversible: the original data cannot be recovered from a hash in a straightforward manner.

Hash functions are used for integrity checks, digital signatures, password storage, and data deduplication. Common cryptographic hash functions include SHA-256 and SHA-3.

For passwords, regular SHA-256 cannot be used without additional measures. Passwords should be stored using specialized functions: Argon2, bcrypt, or scrypt. These slow down brute-force attacks and use salt to ensure that identical passwords do not yield identical values.

Comparison of data encryption methods

Below is a brief table that helps quickly select the appropriate method for the task.

Method	Suitable for	Advantages	Limitations
AES-GCM	API, TLS, files, databases	Fast encryption and integrity verification	Requires unique nonces and correct implementation
ChaCha20-Poly1305	Mobile applications, VPN, TLS	Good speed without hardware AES	Support required in the library and protocol
AES-XTS	Full disk encryption	Suitable for block devices	Not intended for regular messages and API
RSA-OAEP	Protecting small secrets, key exchange	Wide compatibility	Slower than ECC, requires larger keys
ECDH/ECDHE	Agreeing on session keys	Efficiency and forward secrecy	Important to choose secure curves
Ed25519/ECDSA	Digital signatures	Authenticity and integrity verification	Does not hide content of data
Argon2/bcrypt/scrypt	Password storage	Protection against mass brute force	This is not encryption; the password cannot be recovered

If a universal practical choice is needed, for new applications, authenticated encryption like AES-GCM or ChaCha20-Poly1305 is usually considered. For key exchange and secured connections, TLS with modern cipher suites is utilized.

Data encryption at rest, in transit, and in use

To choose a data encryption method, it's helpful to understand the state of the data. The same information may be vulnerable at different points in its lifecycle.

Data at rest

Data at rest is stored on disks, in databases, cloud storage, archives, and backups. Protection can be achieved through:

• full disk encryption;
• encrypting individual files;
• encrypting tables or columns in a database;
• object store encryption;
• encrypting backups before sending them to the cloud.

Full disk encryption protects a device in case of theft or loss. However, it does not always protect data from users or processes that are already logged in. Therefore, for sensitive fields, application-level encryption is often added.

Data in transit

Data in transit moves across the network: between a browser and a website, an application and an API, an office and the cloud, a client and a VPN server. The most common solutions in this case are:

• TLS for HTTPS and API;
• SSH for server administration;
• VPN for secure network tunnels;
• secure protocols for mail and messaging.

The main rule: do not transmit passwords, tokens, documents, and personal data over unprotected channels. Even an internal network should not be considered fully trusted.

Data in use

Data in use resides in memory and is processed by applications. This is a complex area of protection. Regular encryption must decrypt data before processing; otherwise, the application cannot work with it.

For particularly stringent scenarios, trusted execution environments, hardware security modules, and, for specific tasks, homomorphic encryption are applied. However, these technologies are more complex and may not suit all projects.

End-to-end encryption

End-to-end encryption means that data is encrypted on the sender's device and decrypted only on the recipient's device. The intermediary service should not have keys to read the content.

This approach is used in secure messengers, some cloud storage services, and collaboration tools. It reduces the risks associated with server breaches because the server stores or transmits already encrypted data.

However, end-to-end encryption also creates practical challenges:

• recovery of access becomes harder;
• content searches may be limited;
• synchronization between devices requires careful key management;
• administrators cannot easily check contents for policy violations.

Therefore, E2EE is particularly useful for private communication and sensitive documents but requires thoughtful user experience design.

Key management for encryption

Cryptography often fails not due to weak algorithms, but due to poor handling of keys. A key hardcoded in application code or sent via messenger can completely undermine even the most robust encryption.

Key generation

Keys must be generated using a cryptographically secure random number generator. They should not be created manually, nor should dates, names, short phrases, or ordinary pseudorandom number functions from standard libraries without cryptographic purpose be used.

Key storage

Keys should be stored separately from encrypted data. For this, the following can be used:

• KMS in cloud infrastructure;
• HSM for hardware key protection;
• secret managers;
• secure system storage;
• hardware tokens and TPM.

If the database and key are on the same server with no additional protection, compromising the server could expose all data.

Key rotation

Key rotation is a scheduled replacement of keys. It reduces damage in case of a potential compromise and helps maintain internal security policies. However, rotation must be managed: it is essential to know which data is encrypted with which key, where the key version is stored, and how to re-encrypt without losing data.

Separation of duties

Not every administrator should have access to keys. It is advisable to separate roles: some specialists maintain infrastructure, others manage keys, and others analyze logs. This approach reduces the risk of abuse and errors.

How to choose a method of data encryption

Below is a practical step-by-step algorithm suitable for a website, mobile application, corporate system, or a small service.

1. Identify the type of data. Divide information into categories: public, internal, personal, payment, trade secret, credentials.
2. Describe the threats. Consider what needs protection: loss of a laptop, interception of traffic, database breach, insider threat, compromise of a cloud account.
3. Determine the state of the data. Data is at rest, being transmitted across the network, or actively processed by an application.
4. Select a proven algorithm. For large data, use AES-GCM or ChaCha20-Poly1305. For disks — AES-XTS. For key exchange — ECDHE. For passwords — Argon2, bcrypt, or scrypt.
5. Use trusted libraries. Do not write your own cryptography. Choose mature libraries and standard protocols.
6. Set up key management. Decide where keys are created, who has access, how they are rotated, and how they are destroyed.
7. Add integrity control. Prefer authenticated encryption. Do not rely on confidentiality without authenticity checks.
8. Verify recovery. Ensure that backup keys are protected and that the recovery process is clear and tested.
9. Document the solution. Record selected algorithms, parameters, library versions, and access rules.
10. Conduct audits. Regularly update protocols, disable outdated cipher suites, and check access logs.

This approach helps avoid choosing an algorithm "by name" and build a protection system around actual data and risks.

Common mistakes in encryption

Even strong algorithms do not help if they are misapplied. Below are mistakes that occur particularly often.

Homemade cryptography

Creating your own algorithm is almost always a bad idea. Reliable cryptography undergoes years of analysis. It's better to use open standards and tested libraries.

Reusing nonces or IVs

Many modern modes require a unique nonce or initialization vector. Reuse can lead to data exposure. This is especially critical for stream ciphers and modes like GCM.

Storing keys with data

If the key is in the same database or repository as the encrypted data, protection becomes formal. Keys need to be isolated and access restricted.

Lack of integrity verification

Encryption without authentication can allow an attacker to modify encrypted data unnoticed. Therefore, it is better to use AEAD modes: AES-GCM or ChaCha20-Poly1305.

Outdated algorithms and protocols

DES, 3DES, RC4, MD5, and SHA-1 should not be used for cryptographic protection of new systems. Old versions of TLS and weak cipher suites should be disabled as well.

Improper handling of passwords

Passwords should not be stored in plaintext or encrypted in a way that allows their recovery. The correct approach is to hash them with salt and use a slow function, such as Argon2id.

Practical applications

Data encryption methods vary by context. Let's consider a few typical situations.

Protecting a website and API

For a website, setting up HTTPS with a modern TLS configuration is essential. The certificate must be valid, the chain of trust should be correct, and redirection from HTTP to HTTPS should be enabled. For APIs, it is also crucial to secure access tokens, limit their lifespan, and avoid transmitting secrets in URLs.

Database encryption

A database can use encryption at the disk, table, or individual field level. If an attacker obtains a copy of the database file, encryption complicates reading. However, if they gain access to an application with read rights, data could be exposed. Therefore, database encryption should be combined with access control, query audits, and network segmentation.

Backup protection

Backups often contain the most valuable data but are less protected than the main system. They should be encrypted before being sent to external storage. Backup keys should be stored separately. Additionally, recovery should be regularly tested, or else a backup may become useless.

Laptop and mobile device encryption

Full disk encryption protects data upon device loss. In practice, it should be combined with a strong password, screen lock, system updates, and the ability for remote wiping.

Corporate file sharing

For sharing confidential documents, it is better to use services that encrypt data both in transit and at rest, manage permissions, log access, and implement multi-factor authentication. Sending passwords for archives via the same channel as the archives reduces the benefit of protection.

Regulatory and organizational aspects

Encryption is often required not only technically but also organizationally. Companies process personal data, payment information, medical details, and trade secrets. In such cases, it is important to consider applicable laws, agreements, and industry standards.

However, compliance does not boil down to the phrase "data is encrypted." Usually, it is necessary to show what data is protected, what algorithms are applied, who has access to the keys, how auditing is conducted, and what happens in the event of an incident.

It is useful to have an internal cryptographic protection policy. It should specify acceptable algorithms, minimum key parameters, rules for storing secrets, procedures for rotation, and team responsibilities.

The future of encryption and quantum risks

Quantum computers, if they become powerful and affordable enough, may impact asymmetric cryptography. RSA, Diffie-Hellman, and many schemes based on elliptic curves are primarily in danger. Symmetric algorithms will also require attention, but increasing key length partially mitigates the risk.

To prepare for such scenarios, post-quantum algorithms are being developed. Standards and hybrid schemes are already emerging, where classical methods are combined with post-quantum techniques. For most organizations today, it is more important to first eliminate outdated protocols, establish key management, and inventory their cryptography. Then, they can plan to transition to post-quantum solutions where data must remain confidential for many years.

FAQ: frequently asked questions about data encryption

What is the most reliable data encryption method?

There is no one method for all tasks. For large volumes of data, AES-GCM or ChaCha20-Poly1305 is commonly chosen. For secure connections — TLS with modern cipher suites. For passwords, what is needed is not encryption, but Argon2id, bcrypt, or scrypt.

What makes AES-256 better than AES-128?

AES-256 uses a longer key and provides a greater margin of security. However, AES-128 is also considered strong with proper implementation. In real systems, mistakes are often made not in key length but in key storage, mode selection, and protocol configuration.

Can data be encrypted with a single password?

Yes, but the password needs to be transformed into a cryptographic key via a special derivation function, such as Argon2id, scrypt, or PBKDF2 with proper parameters. A password cannot be used directly as a key.

Is it necessary to encrypt data in the cloud?

Yes, if the data is sensitive. Many cloud services encrypt data at rest, but it's important to understand who manages the keys. In critical scenarios, private keys, KMS, HSM, and application-level encryption should be used.

Does encryption protect against viruses and phishing?

Not directly. Encryption hides data from unauthorized reading but does not prevent device infection or protect users from entering passwords on fake websites. Updates, antivirus measures, MFA, training, and access control are necessary.

Which is better: disk encryption or file encryption?

Disk encryption is convenient for protecting a device in case of theft. File encryption is useful when specific documents need to be securely transmitted or stored separately. In corporate environments, both approaches are often used.

Conclusion

Data encryption methods should be selected not based on the popularity of the algorithm but on the task: where the data is located, who accesses it, what threats are most likely, and how the keys will be stored. For new systems, focus on proven standards, use authenticated encryption, protect keys separately from data, and regularly review settings. Start with an inventory of sensitive information, enable TLS, encrypt backups, and implement managed key storage — this will provide a quick and practical boost to security.