Fending Off Attacks (Three Encryption Types That Protect ecommerce)

You have implemented a cryptosystem to protect your ecommerce site, but you may want to ensure that it remains secure from even the most sophisticated attackers. Though many vendors offer techniques that can dissuade the most capable adversary, you should have a basic understanding of what those techniques are — this lesson provides that overview. Lesson 5 catalogued the attack categories: ciphertext-only, known-plaintext, chosen-ciphertext, brute-force, side-channel, and the ecommerce-specific vectors that bypass encryption through application-layer exploits. This lesson defines the three encryption types that defend against those attacks: symmetric encryption, asymmetric encryption, and one-way encryption. A private key might be compared to your house key, and a public key likened to your house number. You give access to the first only to those you know and trust. The second is publicly available information.

How do you fend off the various forms of attack identified in lesson 5? Different strengths of encryption provide the means to defeat attempted security breaches. Encryption strength is a commonly discussed but frequently misunderstood aspect of cryptography — what constitutes strong encryption, what level of encryption is required for various security needs, and how do you determine the effective strength of different encryption types? These questions are addressed in the sections below.

Strong encryption in 2026 means encryption that provides computational security against all currently known and foreseeable attacks — including attacks using the most powerful classical computers, specialized hardware, and the theoretical future capability of quantum computers. The practical definition rests on three interdependent factors: the strength of the algorithm, the secrecy of the key, and the length of the key. Weakness in any one of these factors can undermine an otherwise strong system. An unbreakable algorithm with a compromised key provides zero security; a well-managed key protecting a weak algorithm (DES with a 56-bit key) provides only marginal security against modern brute-force hardware.

The most reliable security comes from industry-standard algorithms that have been publicly analyzed and tested over time by the cryptography research community. Any new or proprietary algorithm — regardless of its creator's claims — should be viewed with significant distrust until it has been verified through years of public cryptanalytic scrutiny. The history of broken "security through obscurity" schemes is long; the algorithms that have survived — AES, RSA, ECC, SHA-256 — did so because they were subjected to the hardest possible public analysis and withstood it.

In terms of encryption and decryption, key length is measured in bits. The number of possible key combinations for a key of length n bits is 2ⁿ — every additional bit doubles the number of possible keys. A 40-bit key has 2⁴⁰ (approximately 1.1 trillion) possible values — a number that specialized hardware can exhaust in under a day. A 128-bit key has 2¹²⁸ possible values — approximately 340 undecillion combinations — which is infeasible to brute-force with all current computing power combined. A 256-bit key extends that margin to 2²⁵⁶, providing security against both classical brute-force attacks and the theoretical threat of quantum computers running Grover's algorithm (which would reduce the effective security of a 256-bit key to approximately 128-bit — still computationally infeasible).

The key length chosen should be directly proportional to the sensitivity of the data being protected and the required protection lifetime. Payment credentials that must be protected for years require longer keys than session tokens that expire in minutes. PCI DSS mandates a minimum of AES-128 for cardholder data encryption; AES-256 is the current recommended standard, providing the additional quantum-resistance margin that long-term data protection requires.

Algorithm strength determines how difficult it is to mathematically reverse the encrypted information without the key — the strongest algorithms make it computationally infeasible to recover plaintext through cryptanalysis alone, even with unlimited time and computing resources short of brute force. No algorithm, however mathematically strong, can protect data from a compromised key. Key secrecy is a logical but frequently overlooked factor: if the encryption key is stored in a plaintext configuration file, hardcoded in application source code, transmitted over an unencrypted channel, or logged in a system log, the mathematical strength of AES-256 is irrelevant. The safety of encrypted data is directly tied to how secret the key remains throughout its entire lifecycle — generation, storage, use, rotation, and destruction.

There are three basic encryption types, which vary primarily in how they use keys. Figure m5-6.1 presents all three side by side — symmetric (private-key), asymmetric (public-key), and one-way (hashing) — with their current 2026 algorithm standards and the specific defense role each plays against the attacks from lesson 5.

In symmetric or private-key encryption, both parties to the communication must possess a single secret key — the same key is used for both encryption and decryption, as shown in the gold panel of Figure m5-6.1. The sender encrypts the plaintext with the shared key; the receiver decrypts the ciphertext with the identical key. Private-key encryption has been around for thousands of years — Caesar's cipher, the Enigma machine, and the simple password are all forms of symmetric encryption where a shared secret controls access to the message. The defining characteristic is the single shared secret: one key, two parties, identical copies.

Private-key encryption presents a fundamental paradox: to use this encryption, a secure channel must exist between the two parties to transfer the shared key — but if such a secure channel already exists, why use encryption at all? The channel needed to deliver the key could have been used to deliver the message directly. This circular dependency prevented symmetric encryption from being used to establish new secure connections between parties who had never previously communicated — which is the exact requirement of every first-time ecommerce transaction. The solution to this paradox is asymmetric encryption, described in Type 2 below.

Despite this paradox, symmetric encryption is the most widely used form of encryption for bulk data — because it is fast, efficient, and computationally inexpensive. The resolution to the key distribution problem is to use asymmetric encryption to securely exchange a symmetric key, then use that symmetric key for the actual data encryption. This hybrid approach is precisely how TLS 1.3 operates.

The Data Encryption Standard (DES) with its 56-bit key was the original widely deployed symmetric algorithm — the gold panel of Figure m5-6.1 notes it explicitly as deprecated and replaced. DES was withdrawn as a standard in 2005 after its 56-bit key was demonstrated to be exhaustible by brute force in under 24 hours using specialized hardware. Triple-DES (3DES) extended the effective key length but at significant performance cost and has itself been deprecated by NIST as of 2023. The Advanced Encryption Standard (AES) replaced both: AES-256 with a 256-bit key is the current standard for ecommerce payment data encryption, mandatory under PCI DSS for cardholder data at rest, and the cipher used within TLS 1.3 sessions in GCM mode (AES-256-GCM).

Symmetric encryption is the correct choice whenever the key distribution problem has already been solved — which in modern ecommerce means whenever a TLS session has been established. Once the TLS handshake has used asymmetric key exchange to derive a shared session key, all subsequent communication in that session is encrypted symmetrically with AES-256-GCM. Database encryption at rest, file system encryption, and full-disk encryption are all symmetric — the key is managed by a key management system rather than transmitted, eliminating the distribution problem. Symmetric encryption's speed advantage over asymmetric encryption (orders of magnitude faster for bulk data) makes it the only practical choice for encrypting large data volumes such as database records, backup files, and high-throughput payment processing streams.

Asymmetric, or public-key, encryption allows parties previously unknown to each other to conduct a secure transaction — the property that makes ecommerce possible at internet scale. In public-key encryption, each party holds two mathematically linked keys: a public key and a private key. As shown in the cyan panel of Figure m5-6.1, the public key is published and widely disseminated — embedded in a digital certificate, available to anyone. The private key is kept secret — never transmitted, never shared. Data encrypted with the public key can only be decrypted with the corresponding private key. Data signed with the private key can be verified by anyone with the public key.

Public-key encryption is relatively recent — it has been in use since the mid-1980s, when RSA was commercialized. The mathematical foundations are the difficulty of factoring large prime number products (RSA) and the discrete logarithm problem on elliptic curves (ECC) — problems that are computationally hard for classical computers but theoretically vulnerable to quantum computers running Shor's algorithm.

Asymmetric encryption resolves the symmetric key distribution paradox by eliminating the need to transmit a shared secret. The public key can travel over an insecure channel — it can be posted publicly — without compromising security, because it can only be used to encrypt, not to decrypt. The corresponding private key, which is the only thing capable of decrypting messages encrypted with the public key, never leaves its owner's secure storage. Two parties who have never communicated can establish a secure channel: one party publishes their public key, the other encrypts a symmetric session key with that public key, and sends the encrypted session key over the insecure network. Only the holder of the private key can decrypt the session key — and once both parties have the session key, symmetric encryption handles the rest.

RSA (Rivest–Shamir–Adleman) was the de facto standard for public-key cryptosystems for decades and remains widely deployed in digital certificates. RSA-2048 is the current minimum recommended key size; RSA-4096 provides additional margin. However, RSA key exchange has been deprecated in TLS 1.3 — it does not provide forward secrecy, meaning a compromise of the server's private key would retroactively decrypt all past sessions recorded by an attacker. Elliptic Curve Cryptography (ECC) provides equivalent security with much shorter keys: a 256-bit ECC key (P-256) provides approximately the same security as RSA-3072, with significantly better performance. ECDH (Elliptic Curve Diffie-Hellman) provides forward secrecy and is the key exchange mechanism in TLS 1.3; ECDSA (Elliptic Curve Digital Signature Algorithm) signs certificates and authentication tokens.

TLS 1.3 made a definitive architectural choice: RSA key exchange was removed from the protocol entirely. All TLS 1.3 key exchange uses ephemeral ECDH — each session generates a fresh key pair, derives the session key, then discards the ephemeral private key. This ephemeral key generation is what provides forward secrecy: even if the server's long-term private key is compromised in the future, recorded past sessions cannot be decrypted because the ephemeral session keys no longer exist. For ecommerce merchants, this means that migrating to TLS 1.3 (and disabling TLS 1.0, 1.1, and 1.2 fallback) is the single configuration change that provides the greatest security improvement against both current and future threats.

One-way encryption — hashing — prevents the resulting cipher from being decrypted. As shown in the green panel of Figure m5-6.1, any input of any length passes through the hash function (SHA-256 in the diagram) and produces a fixed 256-bit digest — with no reverse arrow, because no reverse operation exists. A one-way function is relatively easy to compute in one direction but computationally infeasible to compute in reverse: given a hash output, recovering the original input requires brute-forcing all possible inputs until a match is found. For a 256-bit hash, this is computationally infeasible. This irreversibility makes hashing the correct tool for situations where you need to verify that data is correct without ever storing or transmitting the data itself.

Historically, one-way functions were used for storing passwords on Unix systems (using crypt(), based on DES) and Windows NT systems (using NTLM). Both of those historical implementations are now considered completely broken — NTLM hashes can be cracked in seconds with modern GPU-based rainbow table attacks, and Unix crypt() is similarly obsolete. Modern password storage uses slow, salted, adaptive hash functions specifically designed to resist brute-force and dictionary attacks: bcrypt (the current most widely deployed standard), Argon2 (the winner of the 2015 Password Hashing Competition, now recommended by OWASP), and scrypt (memory-hard, designed to resist hardware acceleration). All three add a unique random salt to each password before hashing — making precomputed rainbow table attacks impossible — and all three are deliberately slow, requiring significant computation per hash to make brute-force attacks economically infeasible even with modern GPU clusters.

For data integrity verification and digital signatures — not password storage — SHA-256 (part of the SHA-2 family) and SHA-3 are the current standards. SHA-256 is used in TLS 1.3 record authentication (HMAC-SHA-256), in digital certificate signatures, in code signing, and in blockchain proof-of-work. SHA-3, based on the Keccak sponge construction, was standardized by NIST in 2015 as an alternative with a fundamentally different mathematical structure — providing resilience against any future weaknesses discovered in SHA-2's design. Both are appropriate for ecommerce integrity verification; SHA-256 is more widely deployed in current infrastructure.

MD5 and SHA-1 — the dominant hash functions of the era when this lesson was originally written — are both cryptographically broken for security purposes. MD5 collision attacks were demonstrated in 2004; it is now possible to create two different files that produce the same MD5 hash in seconds on consumer hardware, completely defeating integrity verification. SHA-1 collision attacks were demonstrated by Google's Project Zero in 2017 (the SHAttered attack). Any ecommerce system using MD5 or SHA-1 for password storage, certificate signatures, or data integrity is operating with broken cryptographic infrastructure. Migration to SHA-256 or SHA-3 for integrity, and bcrypt or Argon2 for passwords, is required for PCI DSS compliance and basic security hygiene.

The primary defense against brute-force attacks is key length. AES-256's 256-bit key provides 2²⁵⁶ possible values — computationally infeasible to exhaust with any foreseeable classical or quantum computing capability. The defense is not algorithm complexity alone but key length combined with algorithm strength: AES-256 with a properly generated, secret, 256-bit key defeats brute-force attacks categorically. The lesson 5 meet-in-the-middle attack that rendered 2DES ineffective does not apply to AES-256 — AES was specifically designed and analyzed to resist meet-in-the-middle and related-key attacks.

The primary defense against man-in-the-middle attacks is certificate verification. When a browser connects to an ecommerce checkout page, the server presents a digital certificate signed by a trusted Certificate Authority (CA). The browser verifies that the certificate's signature is valid, that the domain matches, and that the certificate has not been revoked. This verification — enabled by asymmetric cryptography — confirms that the server is the legitimate merchant and not an impostor. Without asymmetric encryption and the PKI certificate infrastructure it enables, every TLS connection would be vulnerable to an attacker who intercepts the handshake and presents a fraudulent identity. Certificate pinning, HSTS, and CAA DNS records provide additional layers of protection against certificate-based MitM attacks.

The primary defense against credential theft through database breach is one-way hashing. When passwords are stored as bcrypt or Argon2 hashes with unique salts, a complete database breach does not expose the original passwords — the attacker obtains only hashes that cannot be reversed and that require enormous computation to brute-force individually. Even if every hash in the database is cracked eventually, the slow adaptive hash functions ensure that the process takes months rather than seconds, giving the merchant time to detect the breach, notify users, and force password resets. One-way hashing also defends against the rainbow table and dictionary attacks catalogued in lesson 5 — the unique salt per password invalidates all precomputed tables.

Every TLS 1.3 handshake — the security event that occurs each time a customer loads an ecommerce checkout page — deploys all three encryption types in sequence. Asymmetric encryption (ECDH key exchange) establishes the session without transmitting a shared secret, defeating MitM. Symmetric encryption (AES-256-GCM) encrypts all session data with the derived session key, defeating interception and ciphertext-only attacks through key length. One-way hashing (HMAC-SHA-256) authenticates each TLS record, defeating modification attacks and padding oracle exploits by rejecting any tampered record before decryption. The three encryption types are not alternatives — they are complementary layers that each address different attack vectors simultaneously.