Ecommerce Security  «Prev  Next»
Lesson 4 Encryption and decryption
Objective Define encryption and decryption.

Encryption and Decryption (Symmetric, Asymmetric, and One-Way Explained)

Lesson 3 showed AES-256-GCM and TLS 1.3 operating at the checkout boundary — the specific algorithms that encrypt a customer's payment data in transit. This lesson defines the foundational terms those algorithms are built from, and introduces the three categories of encryption that every ecommerce security system uses: symmetric encryption (one key for both operations), asymmetric encryption (a public/private key pair), and one-way encryption (hashing, with no decryption). Together these three cipher types — illustrated in Figure m5-4.1 — form the complete cryptographic toolkit that secures every online transaction from the moment a customer types their card number to the moment the payment processor issues an authorization response.

The Encryption/Decryption Cycle — Figure m5-4.1

In cryptography, a message that humans can read is called plaintext, or cleartext. The process of scrambling a plaintext message to make it unreadable is called encryption, and the resulting scrambled message is called ciphertext. The reverse process — decryption — takes a ciphertext message and restores it to the original plaintext. A key controls both operations: the same key (or a mathematically related key) that encrypts the message is required to decrypt it. Figure m5-4.1 shows the complete cycle, with plaintext entering the key-based encryption engine on the left and complex ciphertext emerging on the right — and the reverse decryption path returning the ciphertext to its original readable form.


Encryption and decryption cycle — plaintext 'Mary had a little lamb' enters the key-based encryption engine producing complex ciphertext; three cipher types shown: symmetric AES-256, asymmetric RSA-2048/ECC, and one-way SHA-256/SHA-3 hashing — 2026 ecommerce cryptography
Figure m5-4.1: The encryption/decryption cycle — plaintext enters the key-based encryption engine and emerges as complex ciphertext (including post-quantum lattice bit-stream simulation); the reverse process (decryption) restores the original message. Three cipher types used in ecommerce: symmetric (AES-256), asymmetric (RSA-2048/ECC), and one-way hashing (SHA-256/SHA-3).

Plaintext — The Original Message

Plaintext is any data in its original, human-readable form — the text of an email, a credit card number, a shipping address, or the contents of a database record. In Figure m5-4.1, the plaintext is represented as 'Mary had a little lamb.' — a deliberately simple example that makes the before-and-after contrast with ciphertext visually obvious. In an ecommerce context, the plaintext that must be protected includes the customer's Primary Account Number (PAN), the card expiration date, the CVV, the billing name and address, and the session authentication tokens that identify the customer's logged-in state. Any of these items transmitted or stored without encryption is vulnerable to interception and misuse.

Encryption — Scrambling with a Key

Encryption is the mathematical transformation of plaintext into ciphertext using a cryptographic algorithm and a key. The algorithm is a defined procedure — a sequence of mathematical operations applied to the plaintext bits. The key is the input that controls how those operations are applied: the same algorithm with a different key produces completely different ciphertext from the same plaintext. This key-dependency is what makes encryption secure: without the key, the algorithm alone cannot reverse the transformation. A cryptographic algorithm used to encrypt and decrypt messages is called a cipher; the keys are the numbers or values used in the cipher's mathematical function. To the human eye, a key looks like a short hexadecimal string — for example: B6AF 5BE5 3C12 9D4A — though a full AES-256 key is 256 bits (32 bytes, 64 hexadecimal characters).

Ciphertext — The Unreadable Output

Ciphertext is the output of the encryption operation — a sequence of bytes that is computationally indistinguishable from random data to anyone who does not possess the decryption key. Figure m5-4.1 shows the ciphertext as 'x$pQ7#gL-8@jK%9d_...[post-quantum lattice bit-stream simulation]...324' — a representation of the scrambled, unreadable format that protects the original data. In real systems, raw ciphertext is binary data; the hexadecimal or base64 encoding used to display it is a presentation layer. The critical property of good ciphertext is that it reveals nothing about the plaintext — not its length, not its structure, not any patterns in the original data. Modern encryption algorithms like AES-256 achieve this through operations that completely diffuse and confuse the plaintext bits across the entire ciphertext block.


Decryption — Restoring the Original

Decryption is the reverse of encryption: applying the cipher algorithm with the correct key to ciphertext to recover the original plaintext. The decryption arrow in Figure m5-4.1 runs in the opposite direction from the encryption arrow — same pipeline, same key mechanism, opposite direction of data flow. In symmetric encryption, the same key is used for both encryption and decryption. In asymmetric encryption, a mathematically related but different key is used for each direction. In one-way hashing, there is no decryption — the transformation is intentionally irreversible.

Cryptographic Keys — The Controlling Mechanism

What a Key Is

A cryptographic key is a string of bits — a binary number — used as input to a cipher algorithm. Keys are typically represented in hexadecimal (base 16) using the characters 0–9 and A–F, grouped in pairs or fours for readability. The key is the variable component of encryption: the algorithm is public and standardized, but the key is secret. All security in a cryptographic system rests on the secrecy of the key — if the key is compromised, all data encrypted with that key is exposed. This is why most attacks on cryptographic systems — a field called cryptanalysis — focus on finding or deriving the encryption key rather than breaking the algorithm directly.

Why Key Length Matters

Key length determines the size of the search space an attacker must explore to find the key by brute force — trying every possible key value until the correct one is found. A 128-bit key has 2128 possible values — approximately 340 undecillion combinations. A 256-bit key has 2256 possible values — a number so large that brute-forcing it with all the computing power currently on Earth would take longer than the age of the universe. AES-128 is considered computationally secure against classical computers; AES-256 provides an additional security margin against future advances in computing power, including the theoretical long-term threat from quantum computers. For this reason, AES-256 is the standard for ecommerce payment data encryption rather than AES-128.

Key Management — The Core Security Challenge

The most technically demanding aspect of operating an encrypted system is not the encryption itself — it is key management: generating keys with sufficient randomness, distributing them securely to all parties who need them, rotating them regularly to limit the damage from a compromise, storing them in hardware security modules (HSMs) that prevent extraction, and revoking them immediately when a compromise is detected. Payment processors and gateway operators maintain dedicated key management infrastructure that is subject to PCI DSS audit. For ecommerce merchants using hosted payment gateways (Stripe, Adyen, PayPal), the gateway's key management infrastructure handles these requirements on the merchant's behalf — one of the primary security advantages of not processing payment data directly.


Symmetric Encryption

One Key for Both Operations

Symmetric encryption — the gold row in Figure m5-4.1's Three Cipher Types panel — uses a single key for both encryption and decryption. The same key that scrambles the plaintext into ciphertext is required to unscramble it back. This single-key architecture makes symmetric encryption fast and computationally efficient: the algorithm applies the same key in forward and reverse directions, and modern hardware implementations of AES can process gigabytes of data per second. This speed makes symmetric encryption the correct choice for encrypting large volumes of data — the body of a TLS session, a database encryption operation, or a file storage encryption system.

AES-256 — The Current Standard

The Advanced Encryption Standard (AES) replaced the Data Encryption Standard (DES) as the US government and international standard for symmetric encryption. DES used a 56-bit key that became vulnerable to brute-force attacks as computing power increased; its replacement Triple-DES (3DES) extended the effective key length but at a significant performance cost and has itself now been deprecated. AES operates on 128-bit data blocks using key lengths of 128, 192, or 256 bits — AES-256 (256-bit key, fourteen rounds of transformation) is the standard for ecommerce payment data. AES has been analyzed extensively since its standardization in 2001 and no practical attack against a correctly implemented AES-256 system has been demonstrated.

The Key Distribution Problem

Symmetric encryption's fundamental limitation is the key distribution problem: before two parties can communicate securely using symmetric encryption, they must first exchange the shared key through a secure channel. But if a secure channel already existed, why not use it to communicate directly? This circular dependency prevented symmetric encryption from being used to establish new secure connections between parties who had never previously communicated — the exact requirement of an ecommerce transaction between a first-time customer and a merchant. The solution is asymmetric encryption, which solves the key distribution problem by eliminating the need to exchange a shared secret.

Asymmetric Encryption

Public and Private Key Pairs

Asymmetric encryption — the cyan row in Figure m5-4.1 — uses a mathematically linked pair of keys: a public key and a private key. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. The public key is freely distributed — published in a digital certificate, shared openly — and anyone can use it to encrypt a message. Only the holder of the corresponding private key can decrypt that message. This eliminates the key distribution problem: two parties who have never communicated can establish a secure channel without first exchanging a shared secret, because the public key can travel over an insecure channel without compromising security.


RSA-2048 and Elliptic Curve Cryptography (ECC)

RSA (Rivest–Shamir–Adleman) was the dominant asymmetric algorithm for decades and remains widely deployed. RSA security relies on the computational difficulty of factoring the product of two large prime numbers — a problem that grows exponentially harder as key size increases. RSA-2048 (a 2048-bit key) is the current minimum recommended key size; RSA-4096 provides additional margin. Elliptic Curve Cryptography (ECC) achieves equivalent security with much shorter keys — a 256-bit ECC key provides approximately the same security as a 3072-bit RSA key — making ECC faster and more efficient for resource-constrained environments such as mobile devices and IoT payment terminals. ECDH (Elliptic Curve Diffie-Hellman) is used for key exchange in TLS 1.3; ECDSA (Elliptic Curve Digital Signature Algorithm) is used for digital signatures in certificates and passkeys. TLS 1.3 dropped RSA key exchange entirely in favor of ECDH.

How TLS Uses Asymmetric to Exchange a Symmetric Key

Asymmetric encryption is computationally expensive — orders of magnitude slower than AES for bulk data encryption. ecommerce systems therefore use asymmetric encryption not to encrypt session data directly, but to securely exchange a symmetric session key. In a TLS 1.3 handshake: the server presents its certificate containing its public key; the client uses ECDH key agreement to derive a shared session key without transmitting it directly; both parties independently derive the same symmetric AES-256-GCM session key from the ECDH exchange; all subsequent session data is encrypted with AES-256-GCM using that symmetric key. This hybrid approach — asymmetric for key exchange, symmetric for bulk encryption — combines the key distribution advantage of asymmetric cryptography with the speed advantage of symmetric cryptography.

One-Way Encryption — Hashing

No Decryption Possible

One-way encryption — hashing — is fundamentally different from symmetric and asymmetric encryption. A hash function takes an input of any length and produces a fixed-length output called a hash, message digest, or fingerprint. The process is intentionally irreversible: given the hash output, it is computationally infeasible to reconstruct the original input. There is no key, no decryption operation, and no reverse path. This one-way property makes hashing unsuitable for encrypting data that needs to be recovered later — but ideal for verifying data integrity, storing passwords, and constructing digital signatures where the goal is confirmation, not recovery.

SHA-256 and SHA-3 — Current Standards

The Secure Hash Algorithm family is the current standard for cryptographic hashing. SHA-256 (part of SHA-2, producing a 256-bit digest) is the most widely deployed hash function in ecommerce systems — used in TLS record authentication, digital certificate signatures, Bitcoin's proof-of-work, and HMAC message authentication. SHA-3 (an entirely different algorithm based on the Keccak sponge construction) was standardized by NIST in 2015 as an alternative to SHA-2 with a different mathematical foundation, providing resilience against any future weaknesses discovered in SHA-2's design. Both SHA-256 and SHA-3 are approved for use in ecommerce security systems.

MD5 and SHA-1 — Deprecated

MD5 (Message Digest 5) and SHA-1 were the dominant hash functions of the early internet era and appear extensively in legacy ecommerce documentation and code. Both are now deprecated for security use: collision attacks against MD5 were demonstrated in 2004 (allowing two different inputs to produce the same hash — undermining integrity verification); SHA-1 collision attacks were demonstrated by Google's Project Zero in 2017 (the SHAttered attack). Any ecommerce system still using MD5 or SHA-1 for password hashing, certificate signatures, or integrity verification is operating with broken cryptographic infrastructure. Migration to SHA-256 or SHA-3 is required.

How Hashing Is Used in ecommerce

Hashing serves three distinct roles in ecommerce security. For password storage, passwords are never stored in plaintext or reversibly encrypted — they are hashed using a slow, salted hash function (bcrypt, Argon2, or scrypt) so that a database breach does not expose the original passwords. For data integrity verification, a hash of the transaction data is computed before transmission and recomputed by the receiver — any modification to the data produces a different hash, immediately revealing tampering. For digital signatures, the document or transaction record is hashed first, then the hash is signed with the private key — signing the hash rather than the original document is faster and produces a fixed-size signature regardless of the document's length.


Post-Quantum Cryptography — The Next Frontier

Why Current Algorithms Face a Long-Term Threat

The ciphertext panel in Figure m5-4.1 includes the label "[post-quantum lattice bit-stream simulation]" — a reference to the next generation of cryptographic algorithms. Current asymmetric algorithms (RSA, ECC) derive their security from mathematical problems — integer factoring and elliptic curve discrete logarithm — that are computationally hard for classical computers but theoretically solvable in polynomial time by a sufficiently powerful quantum computer running Shor's algorithm. A quantum computer capable of breaking RSA-2048 does not currently exist, but the cryptographic community is building the replacement infrastructure now rather than waiting — because data encrypted today with RSA could be harvested and decrypted later when quantum computing matures, a threat model called "harvest now, decrypt later."


NIST Post-Quantum Standards 2024

The US National Institute of Standards and Technology (NIST) finalized the first post-quantum cryptography standards in August 2024. ML-KEM (Module-Lattice Key Encapsulation Mechanism, based on CRYSTALS-Kyber) is the standard for key encapsulation — replacing the ECDH key exchange in TLS. ML-DSA (Module-Lattice Digital Signature Algorithm, based on CRYSTALS-Dilithium) is the standard for digital signatures — replacing ECDSA in certificates. Both algorithms are based on the hardness of lattice problems, which are believed to be resistant to quantum attacks. The "lattice bit-stream" reference in Figure m5-4.1 anticipates this transition.

ecommerce Planning for the Transition

For ecommerce merchants, the post-quantum transition will be largely transparent for those using hosted payment gateways and modern ecommerce platforms — Stripe, Adyen, Shopify, and the major cloud providers (AWS, Azure, Google Cloud) are already implementing post-quantum hybrid TLS configurations that combine classical and post-quantum algorithms during the transition period. Merchants who operate their own TLS infrastructure or process payment data directly will need to plan certificate and key management migrations as browser and server support for ML-KEM and ML-DSA matures through 2025–2027.

How All Three Cipher Types Work Together in One TLS Handshake

A single TLS 1.3 handshake — the event that establishes the secure connection each time a customer loads an ecommerce checkout page — uses all three cipher types in sequence, each contributing its specific security property. Asymmetric encryption (ECDH key exchange) solves the key distribution problem: the client and server derive a shared session key without transmitting it, using each other's public keys and their own private keys. Symmetric encryption (AES-256-GCM) handles the bulk data: every byte of the checkout form submission, every payment field, every HTTP request and response body is encrypted with the session key derived in the handshake. One-way hashing (SHA-256 HMAC) provides per-record integrity: each TLS record carries an authentication tag computed from the record contents and the session key — any modification to any record in transit is detected immediately and the connection is terminated.

The encryption types list from the original lesson — cryptography, DES, one-way encryption, public-key encryption, private-key encryption, cryptographic strength — maps directly to this synthesis. Cryptographic strength is the combined effect of algorithm selection, key length, and correct implementation; it determines how difficult it is to invert the cipher without the key. Every ecommerce transaction depends on all three cipher types operating correctly and simultaneously.

In the next lesson, you will identify various methods of attacking encrypted data.
SEMrush Software 4 SEMrush Banner 4