Encryption protects information against unauthorized reading by transforming plaintext into ciphertext under a cryptographic key. Choosing a sound algorithm matters, but the algorithm alone is not a security design. Teams must also decide where keys are stored, how endpoints are authenticated, whether tampering is detected, and how a compromised key can be retired. A correctly encrypted backup can still be deleted, and a confidential message can still be altered if the surrounding protocol does not verify integrity.
This article compares seven encryption techniques and deployment patterns, rather than pretending that seven cipher names solve the same problem. Some are intended for network messages, others for disks or files, and others help a sender encrypt to a recipient without first sharing a symmetric key. The distinctions are important in practical security engineering and in CompTIA Security+ study, where candidates should understand cryptographic use cases rather than memorize an algorithm list without context.
1. AES-GCM: authenticated encryption for messages
AES is a standardized symmetric block cipher: parties that encrypt and decrypt with it need access to the relevant secret key. AES by itself does not specify how to protect a message of arbitrary length. A mode of operation provides the missing rules, and Galois/Counter Mode (GCM) is an important example because it combines confidentiality with an authentication tag. A receiver checks the tag before accepting protected content as intact. NIST specifies these properties in SP 800-38D.
AES-GCM is appropriate for protocols and applications that need efficient authenticated encryption, including many modern network security designs. Implementers must manage keys and nonces correctly; reusing a nonce with the same key can undermine security. The protection also depends on validating the party at the other end of a connection. A valid GCM tag proves something about the encrypted content under a key, not by itself who should be trusted with that key.
2. XTS-AES: encryption for block-oriented storage
Storage encryption solves a different problem from message encryption. A disk needs to protect many fixed-size data units while supporting reads and rewrites without continuously expanding each sector. XTS-AES is designed for that setting. NIST’s SP 800-38E approves XTS-AES for storage confidentiality but explicitly says the mode does not authenticate the data or its source.
That limitation matters when a device may be tampered with. Encrypting a laptop disk can reduce exposure from a lost device, but it does not prove that operating-system files are unchanged, stop malware running under an unlocked account, or replace backups. Systems therefore combine storage encryption with secure boot, access control, recovery-key management, endpoint security, and restoration testing. A storage technique should not be chosen merely because it shares the AES name with a network cipher suite.
3. ChaCha20-Poly1305: authenticated encryption with a stream cipher
ChaCha20 is a stream cipher, while Poly1305 is used to authenticate the protected data. Their combined authenticated-encryption construction protects both the plaintext and associated data that must remain visible but unchanged. The IETF defines the construction and its nonce requirements in RFC 8439. It is an alternative to AES-based authenticated encryption in supported protocols and software.
ChaCha20-Poly1305 can be useful where consistent software performance matters or specialized AES hardware is unavailable. It is not automatically the right choice for every platform, and its security still depends on key secrecy, unique nonces and correct integration. Developers should use well-maintained cryptographic libraries and standardized protocol configurations rather than adapting the stream cipher and authenticator into an improvised scheme.
4. AES-CBC with an integrity mechanism: understanding older designs
Older applications often use AES in Cipher Block Chaining (CBC) mode. CBC can provide confidentiality when implemented correctly, but unauthenticated ciphertext may be modified in ways that reveal information through errors or change decrypted output. Adding an appropriate message authentication code under a separately managed key can address integrity, provided the protocol combines the operations in a sound construction. This is more complicated to implement safely than using a standardized authenticated-encryption mode.
CBC appears in historical file formats, archives and protocol configurations, so professionals need to recognize and assess it even when designing new systems around AEAD modes such as GCM. Avoid equating “encrypted” with “tamper-proof.” In a legacy migration, inventory the algorithm, mode, padding behavior, authentication method, key lifecycle and recovery implications before selecting a replacement. The cryptographic attacks that matter depend on the complete construction, not simply the cipher name on a configuration screen.
5. RSA-OAEP: public-key encryption for appropriately sized data
Public-key cryptography uses a public/private key pair rather than one shared symmetric secret. RSA-OAEP is a method for encrypting data with an RSA public key so that the corresponding private key can recover it under the specified padding and security assumptions. It is typically used for limited-size inputs, such as an encryption secret, not for bulk streaming data. An application must validate the recipient’s public key through an authenticated channel or trusted binding; otherwise it might encrypt to an attacker’s key.
RSA is also associated with digital signatures, but a signing operation is not the same as public-key encryption. A signature can provide origin and integrity evidence when keys and verification rules are trusted, while encryption addresses confidentiality. That difference sits at the heart of public key infrastructure. Neither primitive should be described as universally more secure than symmetric cryptography: they support different tasks, and meaningful security comparisons depend on parameters, threat models and protocol use.
6. Hybrid Public Key Encryption: combine key establishment and symmetric protection
Hybrid encryption joins the convenient recipient-key model of public-key cryptography with efficient symmetric protection of application data. The sender uses a recipient public key to establish or encapsulate secret material, derives the necessary symmetric keys, and encrypts the payload using an authenticated-encryption algorithm. RFC 9180 specifies a family of Hybrid Public Key Encryption (HPKE) modes and explains how encapsulation, key derivation and AEAD fit together.
HPKE distinguishes a basic mode from authenticated variants; an unauthenticated encryption to a public key does not automatically prove the sender’s identity. Applications must still bind recipient keys to the right identity, handle updates and revocations, and protect private keys. More generally, network protocols such as modern TLS combine key establishment, identity verification and symmetric authenticated encryption. Treating TLS traffic as though every byte were encrypted directly using RSA is an inaccurate model of that design.
7. Envelope encryption: separate data keys from key management
Envelope encryption is a deployment pattern, not another cipher. A service generates or obtains a data-encryption key (DEK) to protect a file, object or database field, then protects that DEK under a separate key-encryption key controlled by a key-management system. Data may be encrypted locally with a fast symmetric algorithm while an approved KMS protects the wrapping key and logs permitted key operations. A well-designed application tracks which key version protected each object so that it can decrypt and rewrap data during a rotation.
This separation limits the blast radius of a single exposed application secret, but it does not remove the need for access control, key rotation planning or audit review. A KMS request log may show use of a wrapping key without showing every subsequent access to data that an application decrypted and cached. Restoring ciphertext without its associated protected DEK can make a backup unusable. Key disposal also needs an explicit retention policy: destroying an old key can make historical records impossible to recover.
How to select encryption without overclaiming its protection
Start with the data flow and attacker model. For network messages, identify authenticated endpoints, the supported protocol versions, cipher suites, nonce requirements and fail-closed behavior. For storage, distinguish a stolen-device confidentiality problem from a malicious disk-write or compromised-account problem. For application records, identify which service can request a decryption, what audit evidence exists and whether backups can be restored under current keys.
Key length matters, but a larger number alone is not a meaningful ranking between unrelated algorithms. Compare security strength under the algorithm’s actual construction and threat assumptions. Strong encryption cannot compensate for weak access credentials, leaked key material, accidental public sharing or a client that fails certificate verification. Likewise, a fast symmetric primitive and a slower asymmetric operation usually play complementary roles, not a contest where one is intrinsically “more secure.”
Historic Triple DES (3DES/TDEA), IDEA, RC6 and Blowfish remain useful names to recognize when auditing older products, but they should not be presented as equivalent choices for a new deployment. In particular, NIST disallowed TDEA for applying new cryptographic protection after December 31, 2023, while still allowing certain processing of already-protected data. A legacy application’s ability to decrypt its old records is not evidence that it should continue creating fresh ciphertext with the same algorithm.
Certification study should connect encryption to actual architecture: where ciphertext is created, how keys become available to authorized principals, how identities are verified, what tampering signals exist, and what happens when recovery is needed. Those questions are more transferable to operational decisions than memorizing seven algorithm names. Good encryption practice is a combination of appropriate primitives, sound protocol integration and an accountable key lifecycle.
