Encryption Algorithms for Developers: Choose AEAD Over Legacy Ciphers

Encryption turns readable plaintext into ciphertext using an algorithm and a key, and decryption reverses it with the correct key. For anything new, choose an authenticated (AEAD) algorithm such as AES-GCM or ChaCha20-Poly1305, and avoid legacy ciphers like DES and 3DES. Key management and unique nonces matter as much as the algorithm you pick.

TL;DR:

• Choose AES 256 GCM on processors with AES instructions; use ChaCha20 with Poly1305 on mobile or embedded devices without hardware acceleration.
• For public key sharing or large files, encrypt the payload with a fresh symmetric key, then protect that small key with the recipient’s public key.
• Generate a new nonce for every message under the same key, store it with the ciphertext, and reject decryption whenever authentication fails.
• Keep keys out of code and configuration files; use secure random generation, protected key storage, and planned rotation or revocation procedures.
• Passwords should be hashed with Argon2id or bcrypt rather than encrypted, because login systems should verify them without recovering their original values.

1. How does an encrypt and decrypt algorithm work?

Think of encryption as a locked box with a published design. Everyone can study how the lock is built, but only the person holding the right key can open it. The same idea drives every modern cipher: the method is public, the key is secret.

In practice the flow is simple. Plaintext goes into an encryption algorithm along with a key, and ciphertext comes out. Decryption applies the inverse operation with the matching key and returns the original text. If the key is wrong, you get noise, or with authenticated encryption, a clear failure instead of garbage.

Three terms get mixed up constantly, so keep them apart:

• Algorithm: the mathematical process, such as AES or ChaCha20, that scrambles and unscrambles data.
• Key: the secret value that steers the algorithm. A strong algorithm with a weak or leaked key protects nothing.
• Mode: the rule for applying a block cipher to data longer than one block, such as GCM or CBC. The mode changes the security properties of the same underlying cipher.

Real systems rarely use just one tool. Most use a hybrid cryptosystem: an asymmetric method such as RSA or elliptic curves exchanges a fresh secret key, then a fast symmetric cipher encrypts the bulk data with it. That is what happens behind the padlock icon in your browser, and it is why you will see both families in the next section.

One caution before moving on. Encryption is reversible by design, which makes it the wrong tool for storing passwords. OWASP’s Password Storage cheat sheet states that hashing is not encryption and recommends adaptive hashing such as Argon2id or bcrypt for passwords. We cover that distinction again in the how-to section.

2. Which cipher type fits your use case: symmetric, asymmetric, block, or stream?

Two questions sort almost every algorithm: how many keys does it use, and how does it process data? Answering them tells you where each cipher belongs.

Symmetric versus asymmetric

• Symmetric ciphers (AES, ChaCha20) use the same key to encrypt and decrypt. They are fast and ideal for bulk data such as files, database fields and network traffic. The hard part is sharing the key safely.
• Asymmetric ciphers (RSA, elliptic-curve cryptography) use a key pair: a public key anyone can see and a private key you guard. They handle key exchange and digital signatures, and they are far too slow for large payloads.

Block versus stream

• Block ciphers such as AES work on fixed-size chunks of data. A mode of operation tells them how to handle messages longer than one block.
• Stream ciphers such as ChaCha20 generate a keystream that is combined with the plaintext byte by byte. They suit software environments without special hardware support.

A good mental map: use asymmetric methods to agree on a key and prove identity, then use symmetric methods to do the heavy lifting. Platform matters too. CPUs with AES hardware instructions favor AES, while phones and small devices without that help often run a stream cipher faster.

Pro Tip: Never pick an asymmetric cipher to encrypt a large file directly. Encrypt the file with a symmetric key, then protect that small key with the public key.

3. Which common algorithms should you actually use?

Here is a practical rundown of the algorithms you will meet most often, and what to do with each.

AES. The Advanced Encryption Standard is a symmetric block cipher with keys of 128, 192 and 256 bits, as described by the IEEE summary. It is the default choice almost everywhere, and the key is to pair it with an authenticated mode. OWASP’s Cryptographic Storage cheat sheet recommends AES with authenticated modes, with keys of at least 128 bits and ideally 256 bits. It also covers envelope encryption, key wrapping and using key derivation functions when keys come from passwords.

ChaCha20-Poly1305. This AEAD construction combines the ChaCha20 stream cipher with the Poly1305 authenticator. According to RFC 8439, ChaCha20 uses a 256-bit key and the combination is well suited to high-performance software implementations. It is an excellent pick where AES hardware acceleration is missing, such as some mobile and embedded platforms.

RSA and elliptic curves. These asymmetric algorithms handle key exchange and signatures. The standard pattern is hybrid: generate a random session key, encrypt your data with it, then encrypt that session key with the recipient’s public key.

DES and 3DES. Retire them. NIST’s block cipher guidance notes that DES has been withdrawn and that 3DES should not be used for encrypting new information. If you inherit a system that uses them, plan a migration instead of extending their life.

Format-preserving encryption (FF1 and FF3). Sometimes a legacy database expects a number in and a number out in the same format. Format-preserving modes keep the output in the same shape as the input. They are a specialized tool for format constraints, not a general-purpose default, and NIST documents them alongside other approved modes on its current modes page.

How the options line up:

NIST’s block cipher page makes the retirement point plainly:

NIST advises that 3DES should not be used for encrypting new information, while AES remains an approved block cipher when paired with appropriate modes of operation, per the NIST block cipher techniques project. If you are starting a project today, the decision is already made for you: AES-GCM or ChaCha20-Poly1305.

A quick selection guide:

• Server hardware with AES instructions: AES-256-GCM.
• Mobile apps or devices without AES acceleration: ChaCha20-Poly1305.
• Sharing a key with another party: a hybrid scheme using RSA or elliptic curves.
• Old fixed-format data you cannot reshape: FF1, after careful review.
• Anything still on DES or 3DES: schedule the migration now.

4. What are modes of operation, and why is AEAD the safe default?

A block cipher by itself only transforms one block. The mode of operation decides how blocks chain together, and that choice can make or break your security. NIST’s SP 800-38 series documents the approved modes, and a quick tour helps you choose.

• ECB: encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks. It leaks patterns. Do not use it for real data.
• CBC: chains each block to the previous ciphertext block. It hides patterns but gives no integrity protection on its own.
• CTR: turns a block cipher into a stream cipher using a counter. It is fast, but again offers no tamper detection by itself.
• GCM and CCM: authenticated modes that provide confidentiality and integrity together. NIST’s SP 800-38D specifies Galois/Counter Mode as an AEAD mode and it is widely used for high-throughput authenticated encryption.
• XTS: designed for encrypting data at rest on storage devices, where each sector is encrypted independently.

AEAD stands for authenticated encryption with associated data. It means the decrypt step checks an authentication tag before releasing any plaintext. If an attacker flips a single bit of the ciphertext, decryption fails loudly instead of quietly producing altered data. AES-GCM and ChaCha20-Poly1305 are the two common AEAD choices, and that integrity check is why they are the practical default.

There is one rule you cannot bend: never reuse a nonce with the same key. In GCM and ChaCha20-Poly1305, reusing a nonce is catastrophic. It can expose plaintext relationships and let an attacker forge messages. Every encryption operation needs a fresh, unique nonce.

Pro Tip: Generate a new random nonce for every message and store it next to the ciphertext. A nonce does not need to be secret, only unique per key.

5. How should you manage encryption keys?

Strong algorithms fail when keys are mishandled. OWASP’s Key Management cheat sheet makes the point directly: effective key management is as important as the algorithm itself. If someone copies your key from a config file, the best cipher in the world cannot help you.

Start with generation. Always use a cryptographically secure random number generator, never a timestamp, a counter or a homemade formula. Then limit how long and how widely each key lives. A cryptoperiod is the span of time a key is allowed to stay in use, and shorter periods reduce the damage from any single leak.

The core habits, in order:

1. Generate keys with a secure RNG from your operating system or a vetted library, and never derive them from predictable values.
2. Separate data encryption keys (DEKs) from key encryption keys (KEKs). The DEK encrypts your data. The KEK encrypts the DEK. This pattern is called envelope encryption.
3. Protect KEKs in a hardware security module (HSM) or a managed key management service wherever possible, so the most valuable key never sits in application memory or on disk.
4. Keep keys out of code, repositories and plain configuration files. Load them at runtime from a protected store.
5. Plan for rotation and revocation from day one. Rotate on a schedule and have a tested procedure for replacing a compromised key.
6. Limit each key’s scope. One key per application, tenant or data set means a leak exposes less.

Envelope encryption also makes rotation cheaper. To rotate a KEK you re-wrap the small DEKs rather than re-encrypting every file, which turns a painful migration into a quick metadata update.

Pro Tip: Test your key recovery and rotation process before you need it. A rotation procedure that has never been run is a guess, not a plan.

6. How do you encrypt and decrypt text step by step?

Here is a safe sequence for encrypting a message or a small piece of text. It follows the guidance above, and none of it requires inventing anything yourself.

1. Choose an AEAD algorithm. AES-256-GCM or ChaCha20-Poly1305 covers nearly every situation.
2. Generate a key with a secure RNG. Use your language’s cryptographic random source, and store the key in a proper secret store rather than in the code.
3. Derive a key from a password only when you must. If users supply a passphrase, run it through a key derivation function such as PBKDF2 or Argon2id with a random salt to produce the encryption key. Do not use the raw passphrase as a key.
4. Create a unique nonce for this message. A fresh random value every time, never reused with the same key.
5. Encrypt. Pass the key, nonce and plaintext to your library. You get back ciphertext plus an authentication tag.
6. Store the pieces together. Keep the nonce, ciphertext and tag as one package. Only the key stays separate and secret.
7. Decrypt and verify. On the way back, the library checks the tag first. If verification fails, reject the message and never use the output.

A few practical notes make this smoother:

• Use maintained cryptographic libraries. Pick a well-reviewed library for your language and never write your own primitives. Subtle mistakes in homemade code are what attackers look for.
• Encode binary output for text channels. Ciphertext is raw bytes, so Base64 is the usual way to put it in JSON, email or a URL parameter. Encoding is for transport only and adds no security.
• Use hybrid encryption for larger payloads. Encrypt the data with a random symmetric key, then encrypt that key with the recipient’s public key and send both.
• Do not confuse hashing with encryption. If the goal is storing passwords for login checks, hash them with Argon2id or bcrypt as described in the OWASP Password Storage guidance. Encrypt only data you need to read back later.

Our own explainer on how secure password manager tools are walks through the same separation between hashing and encryption in a product context.

Finally, remember that a short checklist beats good intentions: AEAD algorithm, secure random key, unique nonce, stored tag, verified decrypt, key kept apart from data.

7. Where do real-world trade-offs show up?

My view is simple: in production, the boring path wins. Use a built-in AEAD from a maintained library, put your keys in a managed store, and spend your effort on rotation, access control and monitoring. Most breaches blamed on “weak encryption” trace back to the surroundings: a leaked key, a reused nonce, a legacy cipher nobody got around to retiring.

The pitfalls repeat. Teams keep DES or 3DES because migration feels risky. Developers reuse a nonce because a counter was easier than randomness. Keys end up in a repository because the deadline was tight. None of these are algorithm problems.

Bring in a cryptography specialist when you design a protocol, handle regulated data, need FIPS-validated modules, or find yourself wanting to combine primitives in a way no standard describes. Or hand the operational burden to a managed provider and keep your attention on your product.

— Mike

8. What if you would rather not run encryption yourself?

Not every team wants to own key rotation, nonce handling and vault security. For those teams, we built managed options. Our cloud storage encryption protects files you keep in the cloud, and our password manager handles credential storage so your people are not improvising with spreadsheets and sticky notes. Together they offer encrypted storage, secret handling and identity protection.

If you want to read more first, our guide on protecting your information in the cloud covers practical habits, and our resources hub lists the product lines we offer. Pick the plan that fits your size on our pricing and comparison page and start with a trial.

FAQ

What is the encryption and decryption algorithm?

An encryption algorithm is a mathematical procedure that uses a secret key to turn readable data into ciphertext. A decryption algorithm performs the inverse operation with the correct key to restore the original. AES is the dominant symmetric example, standardized in FIPS 197, as noted by the IEEE Technology Navigator.

Is PGP still used today?

Yes, PGP-style encryption remains in use for email and file protection, usually in its OpenPGP form. It follows the hybrid pattern: a public key protects a random symmetric key, and a symmetric cipher encrypts the content. For new systems, check whether a modern messaging or storage tool with AEAD fits your needs better.

Is DES still used today?

DES survives in some old systems, but it should not be chosen for anything new. NIST states that DES has been withdrawn and that 3DES should not be used for encrypting new information, per its block cipher guidance. If you find it in your stack, plan a migration to AES-GCM or ChaCha20-Poly1305.

Is it possible to crack AES-256 encryption?

There is no practical known way to break AES-256 by attacking the algorithm itself. Real-world failures come from elsewhere: leaked keys, reused nonces, weak password-derived keys and poor implementations. Protect the key and use an authenticated mode, and AES-256 is not where your risk lives.

Sources

• Csrc
• Password Storage – OWASP Cheat Sheet Series