Primary Applications of Cryptography: Secure Communication, E-Commerce, and Data Protection

Cryptography stopped being an academic curiosity decades ago. Today it silently runs in the background of nearly every digital action — loading a website, sending a text message, swiping a card, or storing a file in the cloud. This article examines the three primary domains where cryptography does its heaviest lifting: secure communication, e-commerce, and data protection, breaking down the actual mechanisms at work in each.

Secure Communication

Transport Layer Security (TLS)

TLS is the protocol responsible for the padlock icon in a browser’s address bar, securing the vast majority of internet traffic (HTTPS, secure email transmission, and API calls). A TLS session unfolds in distinct cryptographic phases:

1. Handshake – client and server agree on a cipher suite and authenticate the server (and optionally the client) using digital certificates.
2. Key exchange – typically via Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), generating a shared session key without transmitting it directly.
3. Bulk encryption – the negotiated session key encrypts application data using a symmetric cipher, typically AES-GCM or ChaCha20-Poly1305.
4. Integrity verification – authenticated encryption modes ensure any tampering with the data in transit is detected.

Simplified TLS 1.3 handshake flow:

Client                                           Server
  |------ ClientHello (supported ciphers) ------->|
  |<----- ServerHello + Certificate + Key -------- |
  |------ Key Exchange + Finished ---------------->|
  |<----- Finished --------------------------------|
  |======= Encrypted Application Data ============|

TLS 1.3, standardized in RFC 8446, removed legacy weak cipher suites and reduced handshake round trips compared to TLS 1.2, improving both security and performance.

Email Encryption

Standard email is transmitted largely in plaintext across intermediate mail servers. Two competing standards address this:

Both rely on a hybrid approach: the message body is encrypted with a fast symmetric cipher, and only the symmetric key itself is encrypted with the recipient’s public key — combining the speed of symmetric encryption with the key-management convenience of asymmetric cryptography.

End-to-End Encrypted Messaging

Applications like Signal, WhatsApp, and iMessage use protocols specifically designed so that even the service provider cannot read message content. The Signal Protocol (also called the Double Ratchet Algorithm) combines:

• X3DH (Extended Triple Diffie-Hellman) for initial key agreement between users who have never communicated before
• Double Ratchet for continuously deriving new keys per message, providing forward secrecy (past messages stay secure even if a current key is compromised) and post-compromise security (future messages regain security after a compromise is remedied)

$$ K_{n+1} = \text{KDF}(K_n, \text{DH output or message counter}) $$

This constant key rotation means that compromising one message’s key does not expose the entire conversation history — a critical property for high-stakes communication.

Virtual Private Networks (VPNs)

VPN protocols like WireGuard, OpenVPN, and IPsec create encrypted tunnels between a device and a remote network, typically combining:

• Asymmetric key exchange for tunnel establishment (e.g., Curve25519 in WireGuard)
• Symmetric encryption for the actual data tunnel (ChaCha20 or AES)
• HMAC or Poly1305 for packet integrity verification

E-Commerce

Securing Online Payments

Every online card transaction depends on layered cryptography:

1. TLS secures the connection between the customer’s browser and the merchant’s server.
2. Payment tokenization replaces raw card numbers with single-use or merchant-specific tokens, so even if a token leaks, it can’t be reused elsewhere.
3. EMV chip cryptography on physical cards uses dynamic cryptograms generated per transaction, preventing card-present fraud through simple data copying.

PCI DSS and Cryptographic Compliance

The Payment Card Industry Data Security Standard (PCI DSS) mandates specific cryptographic controls for any organization handling cardholder data, including strong encryption for cardholder data at rest and in transit, secure key management practices, and prohibition of deprecated algorithms like DES or unsalted hashes for sensitive fields.

Digital Signatures in E-Commerce

Digital signatures authenticate transactions and contracts without requiring physical presence:

$$ \text{Signature} = \text{Sign}(K_{priv}, H(\text{transaction data})) $$

E-invoicing systems, digital contracts, and API request signing (used heavily by cloud providers like AWS, which signs every API request using HMAC-based request signing) all rely on this pattern to prove that a request or document is authentic and unmodified.

Cryptocurrency and Digital Payments

Cryptocurrencies extend cryptographic e-commerce further by removing the need for a trusted intermediary entirely:

Secure Web Authentication for Merchants and Customers

Customer accounts on e-commerce platforms rely on the authentication mechanisms described in the companion “Principles of Cryptography” article: salted password hashing with Argon2 or bcrypt, TOTP-based two-factor authentication, and increasingly FIDO2/WebAuthn passkeys that eliminate passwords entirely by relying on device-bound key pairs.

Data Protection

Encryption at Rest

Data stored on disks, in databases, or in cloud storage buckets is protected using encryption at rest, typically implemented at one of several layers:

Key Management: The Hidden Backbone of Data Protection

Encryption is only as strong as the key management supporting it. A Key Management System (KMS) handles the full lifecycle of cryptographic keys:

1. Generation – using cryptographically secure random number generators (CSPRNGs)
2. Storage – often within a Hardware Security Module (HSM) that never exposes raw key material
3. Rotation – periodically replacing keys to limit the exposure window if a key is compromised
4. Revocation and destruction – securely retiring keys that are no longer needed or that may be compromised

Envelope encryption, widely used by cloud providers, illustrates a common key-hierarchy pattern:

$$ \text{Data} \xrightarrow{\text{Data Encryption Key (DEK)}} \text{Encrypted Data} $$

$$ \text{DEK} \xrightarrow{\text{Key Encryption Key (KEK), stored in HSM}} \text{Encrypted DEK} $$

Only the encrypted DEK is stored alongside the data; the KEK — which never leaves the secure HSM boundary — is required to unwrap it, drastically limiting the exposure of the most sensitive key material.

Data Loss Prevention and Backup Protection

Cryptography also protects data during backup and transfer processes:

• Encrypted backups prevent exposure if backup media is lost or stolen
• Client-side encryption (zero-knowledge architecture) ensures that even the storage provider cannot read uploaded data, used by services like certain password managers and privacy-focused cloud storage providers

Data Masking and Tokenization

For scenarios where full encryption isn’t practical (e.g., analytics on production-like data), organizations use:

• Tokenization – replacing sensitive data with a non-reversible or securely reversible token, keeping the mapping in a separate, tightly controlled vault
• Format-preserving encryption (FPE) – encrypts data while preserving its original format (e.g., a 16-digit encrypted output for a 16-digit card number), simplifying integration with legacy systems that expect specific data formats

Cryptography in Enterprise Security Workflows

Beyond the three headline domains, cryptography shapes day-to-day professional security operations in ways that deserve explicit attention.

Identity and Access Management (IAM)

Enterprise IAM systems rely heavily on cryptographic tokens rather than raw credentials passed between systems:

• SAML (Security Assertion Markup Language) – uses XML digital signatures to let an identity provider assert a user’s identity to a service provider without that service provider ever seeing the user’s password.
• OAuth 2.0 / OpenID Connect – uses signed JSON Web Tokens (JWTs), where the signature (typically HMAC or RSA/ECDSA-based) allows a resource server to trust claims about a user without contacting the identity provider on every request.

$$ \text{JWT} = \text{Base64Url}(\text{Header}) \parallel \text{“.”} \parallel \text{Base64Url}(\text{Payload}) \parallel \text{“.”} \parallel \text{Signature} $$

Secure Software Development Workflows

Modern DevSecOps pipelines embed cryptography directly into the software delivery process:

• Code signing – ensures binaries and container images haven’t been tampered with between build and deployment.
• Software Bill of Materials (SBOM) signing – increasingly used to cryptographically attest to the components included in a software release, addressing supply-chain security concerns highlighted by incidents like the SolarWinds breach.
• Git commit signing (GPG/SSH signatures) – allows verification that a code commit genuinely originated from the claimed developer, protecting against source-code tampering or impersonation in collaborative repositories.

Secure Enterprise Communication

Beyond consumer messaging apps, enterprises deploy cryptography through:

• Secure file transfer protocols (SFTP over SSH, FTPS) replacing legacy unencrypted FTP
• Zero Trust Network Access (ZTNA) architectures, which authenticate and encrypt every connection individually rather than trusting traffic based on network location alone
• Hardware security keys (YubiKey and similar FIDO2 devices) for phishing-resistant employee authentication

A Typical Professional Cryptographic Security Workflow

Security teams generally follow a structured process when applying cryptography to protect a new system or data flow:

1. Data classification – determine sensitivity level (public, internal, confidential, restricted) to decide what protection is actually warranted.
2. Threat modeling – identify realistic attackers and attack vectors (network eavesdropping, insider threats, stolen devices, etc.) relevant to the specific data flow.
3. Algorithm and protocol selection – choose current, standards-based algorithms (AES-256-GCM, TLS 1.3, ECDSA P-256 or higher) rather than legacy or custom-designed schemes.
4. Key management design – define how keys will be generated, stored (ideally in an HSM or KMS), rotated, and eventually retired.
5. Implementation using vetted libraries – avoid hand-rolled cryptographic code; use maintained, widely audited libraries (OpenSSL, libsodium, platform-native crypto APIs).
6. Testing and review – includes code review focused specifically on cryptographic misuse patterns, and where feasible, third-party security audit or penetration testing.
7. Monitoring and rotation – ongoing monitoring for algorithm deprecation notices (e.g., NIST transition guidance) and scheduled key rotation.

Limitations of Cryptography in Practice

It’s worth being explicit about what cryptography cannot do, since over-reliance on it is a common source of false security confidence:

• Cryptography protects data, not systems — a perfectly encrypted database offers no protection if an attacker can authenticate as a legitimate application and simply query decrypted data through normal channels.
• Cryptography cannot compensate for weak key management — the most mathematically sound algorithm is worthless if its key is exposed.
• Cryptography does not prevent metadata leakage — encrypted traffic can still reveal who is communicating with whom, how often, and how much data is exchanged, even if content remains hidden (an important consideration for anonymity-focused applications like Tor).
• Cryptography does not protect against endpoint compromise — if an attacker controls the device where data is decrypted for use, encryption elsewhere in the pipeline provides no protection at that point.

Cross-Domain Table: Cryptography’s Real-World Footprint

Emerging Application: Confidential Computing

An increasingly important application extends cryptographic protection to data while it is actively being processed, not just while stored or transmitted. Traditional encryption leaves data exposed in plaintext form in system memory during computation — a gap that confidential computing addresses using hardware-based Trusted Execution Environments (TEEs) such as Intel SGX, AMD SEV, and ARM TrustZone.

These technologies create encrypted, isolated memory regions (“enclaves”) where code and data remain encrypted even from the host operating system or hypervisor, protecting against threats including malicious cloud administrators or compromised host infrastructure. This is particularly relevant for e-commerce and financial applications processing sensitive data in shared cloud environments, and for multi-party data analysis scenarios where organizations want to jointly compute results without exposing their raw underlying data to each other.

Application in Regulatory Compliance

Cryptography’s applications are frequently shaped directly by regulatory requirements rather than purely technical preference:

Security professionals working in regulated industries must map cryptographic application choices directly to these frameworks, since using an unapproved algorithm or an insufficiently validated cryptographic module can create compliance failures even if the underlying security is technically reasonable.

Common Mistakes in Applying Cryptography Across These Domains

• Encrypting data in transit but neglecting encryption at rest, leaving stored data exposed if the storage layer itself is compromised.
• Hardcoding encryption keys directly in application source code instead of using a dedicated key management system.
• Assuming HTTPS alone secures an e-commerce application, while ignoring server-side vulnerabilities like insecure direct object references that bypass cryptographic protections entirely.
• Using deprecated cipher suites or TLS versions (like TLS 1.0/1.1) still supported for “compatibility,” creating an unnecessary attack surface.

Frequently Asked Questions

Q: Why does e-commerce need more than just TLS? TLS only protects data in transit between the browser and server. It does nothing to protect stored cardholder data, prevent application-layer vulnerabilities, or verify transaction authenticity after the data reaches the server — all of which require additional cryptographic and procedural controls like tokenization and PCI DSS compliance.

Q: What is the difference between encryption at rest and encryption in transit? Encryption in transit protects data while it moves across a network (e.g., TLS). Encryption at rest protects data while it is stored on disk, in a database, or in cloud storage. A fully secure system needs both.

Q: Why is key management considered more important than the encryption algorithm itself? Even the strongest algorithm (like AES-256) provides no protection if its key is poorly generated, exposed in logs, hardcoded in source code, or never rotated. Most real-world cryptographic failures stem from key management mistakes rather than algorithmic weaknesses.

Q: How does end-to-end encryption differ from standard TLS-protected messaging? With standard TLS, the service provider’s servers can decrypt and read messages in transit (even if the connection to the user is encrypted). End-to-end encryption ensures only the communicating users hold the keys needed to decrypt content, so even the service provider cannot read it.

Summary

Cryptography’s practical value becomes clearest when examined through its primary real-world applications. In secure communication, TLS, email encryption, and protocols like Signal protect data as it moves across the internet. In e-commerce, tokenization, EMV cryptograms, and digital signatures protect financial transactions and prove their authenticity. In data protection, encryption at rest, envelope encryption, and disciplined key management protect information wherever it is stored. Across all three domains, the same underlying principles — confidentiality, integrity, authentication, and access control — are applied through different but conceptually related tools, reinforcing why understanding the principles matters more than memorizing any single implementation.

References

• IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3.
• IETF RFC 4880, OpenPGP Message Format.
• Marlinspike, M., & Perrin, T. (2016). The Double Ratchet Algorithm, Signal Foundation.
• PCI Security Standards Council, Payment Card Industry Data Security Standard (PCI DSS) v4.0.
• NIST Special Publication 800-57 Part 1 Rev. 5, Recommendation for Key Management.
• NIST Special Publication 800-38G, Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption.