Field Journal

Cryptography / Decision Guide

Symmetric vs Asymmetric Cryptography

Symmetric and asymmetric cryptography are complementary mechanisms serving distinct architectural roles. Symmetric ciphers provide high-throughput bulk encryption using a shared secret key, whereas asymmetric cryptography uses public/private key pairs for public-key distribution and digital signatures. A signature validates for data under a public key; signer attribution and evidence of key control additionally require an authenticated identity binding and trustworthy key custody.

Direct Comparison Matrix

Dimension Symmetric Cryptography Asymmetric Cryptography Primary Operational Trade-off
Attribution Capability Shows that a valid tag came from some holder of the shared key; it cannot distinguish which holder created it Verifies that a signature validates for specific data under a public key. Attribution to a person depends on an authenticated key-to-identity binding and evidence that the private key remained under that person’s control; a copied, shared, delegated, or compromised key breaks that chain. Legal non-repudiation further depends on jurisdiction and evidentiary standards Symmetric MACs cannot distinguish among key-sharing parties; signatures can support attribution only with separate identity and custody evidence.
Computational Throughput Extremely fast (Gigabytes/sec via hardware AES-NI) Computationally far more expensive per byte — commonly cited as roughly two to three orders of magnitude slower, though the actual ratio varies widely by algorithm, key size, and hardware acceleration; consult a current benchmark (e.g., openssl speed) for figures on your target platform rather than treating any single number as universal Use asymmetric crypto to exchange keys, then symmetric ciphers for bulk data.
Data Size Limits Arbitrary message length Applies to public-key encryption specifically (e.g., RSA-OAEP), not to signatures or key agreement: RSA-2048 with OAEP-SHA256 encrypts ≤ 190 bytes (modulus_bytes − 2×hashLen − 2). ECDSA/EdDSA sign a fixed-size digest regardless of message length, and ECDH/X25519 key agreement has no payload to size-limit at all. Asymmetric encryption wraps symmetric keys rather than encrypting bulk files; signatures and key agreement aren’t subject to this limit in the first place.
Key Architecture Single shared secret key (K) Linked Key Pair: Public Key (Kpub) + Private Key (Kpriv) Symmetric keys require secure out-of-band distribution or key agreement.
Key Distribution Requirement Requires pre-shared secret key over secure channel Public key can be distributed freely; binding requires authentication (PKI) Public keys eliminate shared secret transport but require an authenticated binding — X.509 certificates are the common mechanism, but out-of-band fingerprint verification and pinned keys are also used.
Post-Quantum Resilience Grover’s algorithm gives an ideal sequential key-search query bound of roughly 2^(n/2), but concrete attack cost also depends on circuit depth, error correction, oracle cost, and available hardware. AES-128 remains NIST’s Category 1 comparison baseline; AES-256 provides additional margin. RSA and ECC would be rendered tractable to break by Shor’s Algorithm once a sufficiently capable, fault-tolerant quantum computer exists (none does today). A future CRQC would require migration away from classical asymmetric primitives. Symmetric key size remains a profile- and threat-model decision rather than a universal doubling rule.
Primary Architectural Role Bulk payload encryption at rest and in transit Key exchange, digital signatures, identity authentication Complementary paradigms combined in hybrid encryption protocols.
Primary Primitives AES-256-GCM, ChaCha20-Poly1305, HMAC-SHA256 RSA-OAEP / PSS, ECDSA, Ed25519, X25519 Modern protocols prefer AEAD (AES-GCM) and ECC (Ed25519 / X25519).

Hybrid Encryption Architecture: Combining Both Primitives

Production systems rarely use asymmetric cryptography to encrypt large files or database fields directly. Instead, protocols combine asymmetric key exchange with symmetric bulk encryption in a Hybrid Encryption pattern:

Hybrid encryption sequence using a random symmetric DEK for data and the recipient's public key to protect that DEK.

Asymmetric cryptography protects the DEK; symmetric cryptography protects the bulk payload

Standardized Hybrid Protocols

  1. HPKE (Hybrid Public Key Encryption, RFC 9180): Modern standard combining KEM key encapsulation, KDF key derivation, and AEAD symmetric encryption.
  2. TLS 1.3 (RFC 9846, which obsoletes the original RFC 8446): Certificate-authenticated full handshakes use ephemeral key establishment, commonly X25519 or the hybrid X25519MLKEM768 group defined by RFC 10024, followed by HKDF and a negotiated AEAD such as AES-GCM or ChaCha20-Poly1305. TLS 1.3 also permits PSK-only operation, which does not provide forward secrecy for that connection.
  3. OpenPGP (RFC 9580): Encrypts files/messages using a symmetric session key wrapped under the recipient’s RSA or ECC public key.

Cryptographic Objective Selection Matrix

System Engineering Objective Selected Cryptographic Paradigm Recommended Standard Operational Mechanics
Bulk Data Confidentiality at Rest Symmetric Encryption AES-256-GCM for records, objects, and files; AES-XTS (not GCM) for block-device/disk-volume encryption Encrypt database fields, files, and objects using AES-GCM within a DEK/KEK hierarchy; full-disk/block-device encryption conventionally uses AES-XTS instead (see Full-Disk & File Encryption) since fixed-size disk sectors don’t have room for an AEAD tag.
Key Encapsulation to Single Receiver Asymmetric HPKE HPKE (RFC 9180) Sender’s KEM operation against the receiver’s public key yields a shared secret, which HKDF expands into an AEAD context (key + nonce schedule) used to encrypt the payload directly; using that context to wrap a separate DEK is one common application pattern, not HPKE’s only mode of operation (RFC 9180 also defines PSK and auth modes).
Network Transit Confidentiality Hybrid Encryption TLS 1.3 (ephemeral key establishment + HKDF + negotiated AEAD) A certificate-authenticated full handshake uses an ephemeral group such as X25519 or X25519MLKEM768 to establish shared keying material; HKDF derives the traffic secrets and keys used by the negotiated AEAD.
Payload Integrity & Authentication Symmetric MAC HMAC-SHA256 Both endpoints share secret key; verifier checks HMAC tag over message.
Unforgeable Signature Evidence Asymmetric Digital Signature Ed25519 (RFC 8032) / RSA-PSS Signer uses a private key; verifier checks that the signature validates for the payload under the public key. Identity and custody remain separate checks.

Critical Cryptographic Boundary Rules

  1. Do Not Encrypt Large Payloads with RSA: RSA modular exponentiation is slow and constrained by modulus size. Use HPKE or a hybrid construction.
  2. Symmetric MACs Do Not Provide Non-Repudiation: A shared-key HMAC tag proves the message was created by a holder of the key, which includes both sender and receiver. A private-key digital signature is necessary evidence toward non-repudiation, not a guarantee by itself — the complete outcome also depends on the key-to-identity binding, key custody, and evidence handling (see the attribution row above and the signature-verification checklist on the Digital Signatures page).
  3. Validate Public Key Identity Bindings: Exchanging public keys over an unauthenticated channel leaves endpoints vulnerable to Man-in-the-Middle (MitM) key substitution. Bind public keys using PKI X.509 certificates or out-of-band fingerprint verification.
What I need to remember

Symmetric encryption is far faster per byte but requires shared keying material; asymmetric cryptography can establish or protect that material, but only once the public key itself is authenticated. Production systems combine them: authenticated key agreement or a KEM establishes session keying material, while public-key encryption can wrap a per-object DEK; the resulting symmetric keys protect bulk data within protocol-defined usage and lifetime limits.

Primary references