Symmetric and Asymmetric Encryption

1. Overview

A. Definition

Symmetric key cryptography uses the same secret key for both encryption and decryption, whereas asymmetric cryptography (public-key cryptography) uses a mathematically paired public/private key pair, designed so that whatever is encrypted with one key can be decrypted only with the other.

The fundamental difference between the two lies in whether the key is "shared" or "split." Symmetric encryption requires the sender and receiver to share the same secret in advance, so computation is fast, but the problem of delivering that secret securely always remains. Asymmetric encryption splits the key into a public part and a secret part: the public key is distributed to anyone, while the private key is held secretly by its owner alone. Thanks to this "asymmetry" (exposing one side does not allow the other to be derived), secure communication and identity proof become possible even with a stranger with whom nothing was shared beforehand.

The two approaches should be understood not as competitors but as complementary partners with different roles. Symmetric encryption is a "fast vault," and asymmetric encryption is a "means of handing over the key safely." Real protocols almost always use both together. From a professional engineer's standpoint, what matters is understanding each approach's mathematical foundation (hard problem) and performance characteristics, and the ability to design a combination that fits the given security requirements (confidentiality, integrity, authentication, non-repudiation) along with performance and regulatory constraints.

B. Background and Necessity

Early ciphers were all symmetric, and as the number of participants grew, key distribution became a hard problem. For n people to communicate one-to-one, n(n-1)/2 secret keys are required, and how to share these keys securely itself demanded yet another secure channel. "To exchange encrypted messages you must first share a key securely, but to share that key securely you need yet another cipher" — this circular problem was a longstanding wall in cryptography.

In 1976, Whitfield Diffie and Martin Hellman broke this cycle by proposing the concept of public keys and a key exchange protocol, and in 1977 Rivest, Shamir, and Adleman implemented it as a practical algorithm with RSA. Public-key cryptography, with its breakthrough of "being able to agree on a secret over a public channel with no prior sharing," became the foundation of e-commerce, internet banking, and the certificate-based trust framework (PKI).

However, public-key operations involve heavy mathematical computations such as exponentiation of large integers, making them hundreds to thousands of times slower than symmetric encryption and unsuitable for encrypting large volumes of data. Thus practice takes only the strengths of both approaches with a hybrid structure that exchanges keys securely with asymmetric encryption and then rapidly encrypts the actual content with symmetric encryption. This structure is the common backbone of today's HTTPS, VPNs, and end-to-end messenger encryption.

C. Key Characteristics of the Two Approaches

Symmetric: Computation is fast and implementation is simple, making it suitable for bulk and real-time processing, but a secret key must be securely pre-shared with each counterparty, and by the nature of sharing, non-repudiation does not hold.
Asymmetric: Secure communication, digital signatures, and non-repudiation are possible in open environments without prior sharing, but the heavy computation makes it unsuitable for encrypting content, and a trust foundation (PKI, certificates) that guarantees a public key truly belongs to its claimed owner is indispensable.
Common premise: In either approach, security depends entirely on "keeping the key secret," following Kerckhoffs's principle that a system is secure as long as the key is safe, even if the algorithm is public.

2. Comparison of Mechanisms and Mathematical Foundations

A. Overall Structure Diagram

flowchart LR
  subgraph SYM["Symmetric encryption (same key)"]
    A[Plaintext] -->|secret key K| B[Ciphertext] -->|same secret key K| C[Plaintext]
  end
  subgraph ASYM["Asymmetric encryption (public/private key)"]
    D[Plaintext] -->|receiver public key| E[Ciphertext] -->|receiver private key| F[Plaintext]
  end

In the symmetric approach, a single secret key is used as-is for both encryption and decryption, so computation is simple and fast. Block ciphers such as AES consist of relatively lightweight bit operations that repeat substitution-permutation (SPN) or Feistel structures over multiple rounds, and with modern CPUs' hardware-acceleration instructions (AES-NI), they process several GB per second. In other words, they are suitable for high-volume traffic and disk encryption where performance matters. This repetition of confusion and diffusion erases the statistical correlation between plaintext and ciphertext, making the cipher hard to break by anything other than brute force.

By contrast, asymmetric encryption rests its security on mathematical hard problems. RSA is based on the integer-factorization problem ("the product of two large primes is easy to compute, but factoring that product back is extremely hard"), while ECC (elliptic-curve cryptography) is based on the problem that "point addition on an elliptic curve is easy, but its inverse (the discrete logarithm) is hard." Since the private key cannot be derived from the public key within any realistic time even when the public key is disclosed, there is no need to pre-share keys. The trade-off is that the high computational cost makes it unsuitable for large-volume processing.

B. Characteristics Comparison and Trade-offs

Category	Symmetric encryption	Asymmetric encryption
Key	Same secret key	Public/private key pair
Speed	Fast	Slow (hundreds to thousands of times)
Key distribution	Hard (requires pre-sharing)	Easy (distribute public key)
Number of keys	n(n-1)/2	2n
Basis of security	Confusion/diffusion of substitution-permutation	Integer-factorization/discrete-logarithm hard problems
Representative algorithms	AES, SEED, ARIA, LEA, DES (deprecated)	RSA, ECC, ElGamal, DH
Main use	Encrypting large data	Key exchange, digital signatures, authentication

The difference in the number of keys illustrates the core trade-off well. When 100 people communicate with one another, symmetric encryption requires generating, storing, and retiring about 4,950 keys (=100×99/2), whereas asymmetric encryption needs only one pair each, for 200 total. In other words, the more participants there are and the more open the environment with no prior relationships, the more the key-management advantage of asymmetric encryption is maximized. Conversely, in closed networks and storage encryption where a small, fixed set of parties exchanges large volumes of data, symmetric encryption is overwhelmingly advantageous.

The speed gap is tangible in numbers. On a server-grade CPU, AES-256 encrypts several GB per second, whereas RSA-2048 signature verification runs on the order of thousands to tens of thousands per second, and signature generation is even slower. For this reason, designs that "encrypt the content itself with a public key" are almost never used for performance reasons; the public key is applied only to a small session key or hash value.

The difference in the basis of security also has large implications. The security of symmetric encryption lies in "the key space being too large for exhaustive search," so as long as the key is long enough it can hold up relatively well even in the quantum-computing era (Grover's attack only speeds up search to the square-root level). Asymmetric encryption, by contrast, rests on the "hardness" of a specific mathematical problem, so if an algorithm that breaks that problem (e.g., quantum Shor) appears, it collapses regardless of key length. This structural difference is the core backdrop for the PQC transition discussed later.

C. Modes of Operation for Symmetric Ciphers

Because symmetric block ciphers process plaintext by dividing it into fixed-size blocks (128 bits for AES), the mode of operation, which determines how blocks are chained and iterated, governs security. The simplest ECB mode makes identical plaintext blocks always produce identical ciphertext, revealing patterns, so it is effectively prohibited. CBC mixes the ciphertext of the previous block into the next block to remove patterns, but it does not guarantee integrity.

Today's de facto standard is an authenticated encryption (AEAD) mode such as AES-GCM. By generating an authentication tag simultaneously with encryption, it provides "confidentiality + integrity + authentication" in one step, reducing the implementation mistakes that arose when attaching a separate MAC. In addition, the CTR family allows parallel processing, making it suitable for high-speed networks. In a professional engineer's answer, writing not just "use symmetric encryption" but which mode and why reveals depth.

A factor easily overlooked in mode selection is initialization vector (IV)/nonce management. For CBC, CTR, and GCM alike, reusing the same IV with the same key causes security to collapse rapidly; in particular, GCM can expose even the authentication key if the nonce is reused, which is fatal. Therefore the IV must be managed to be unpredictable (CBC) or to never repeat (GCM), which illustrates well the principle that "even if the algorithm is secure, operation governs security."

D. Domestic Algorithms and Key Lengths

Domestic public and financial systems are often recommended or required to use domestic symmetric algorithms developed and validated by KISA, such as SEED (128-bit block), ARIA (128/192/256), and LEA (lightweight). ARIA is registered as both a national standard (KS) and an international standard, and LEA is a lightweight, high-speed cipher aimed at resource-constrained environments such as IoT and mobile. In the digital-signature and authentication domain, domestic public-key signature algorithms (KCDSA/EC-KCDSA) are used as well.

For secure key lengths, AES-128 or higher is common for symmetric encryption (256 for long-term protection), and RSA-2048 or higher for asymmetric encryption (3072 or higher for long-term protection); ECC (e.g., 256 bits ≈ RSA 3072 bits), which achieves the same security strength with a shorter key, is preferred in mobile and IoT. The shorter the key, the lower the computation, storage, transmission, and power burden, so the practical implications of ECC are especially large in sensor nodes and smart cards with limited battery and bandwidth.

3. Security Services Provided

The choice of cryptographic approach depends on "which security services are needed." Beyond the core goals of information protection — confidentiality, integrity, and availability (CIA) — there are authentication and non-repudiation, and the design must distinguish which approach achieves each goal and how.

Confidentiality can be provided by both symmetric and asymmetric encryption, but because of performance, in practice the content is encrypted with symmetric encryption and only its session key is protected with asymmetric encryption. No matter how large the plaintext, symmetric encryption handles the encryption, while asymmetric encryption takes only the role of "handing over the small key securely" — this is the standard.

Authentication and non-repudiation are the distinctive strengths of asymmetric encryption. When a sender signs with their private key, anyone can verify it with the sender's public key, and since only the sender holds the private key, they cannot later deny "having signed it." With symmetric encryption, both parties share the same key, so it is impossible to prove to a third party "which of the two created it," and non-repudiation does not hold. This difference is why digital signatures and certificates are necessarily public-key-based.

Integrity is guaranteed by signing the hash value of the original (such as SHA-256) or attaching a message authentication code (MAC/HMAC): if even one bit is tampered with in transit, the hash/MAC changes and verification fails. A digital signature provides "integrity + authentication + non-repudiation" simultaneously, whereas HMAC, being symmetric-key-based, is fast but does not provide non-repudiation. Thus one selects according to the requirement — HMAC for internal communication where "only tampering between the two needs to be prevented," and a digital signature for electronic documents and electronic contracts where "the author must be proven to a third party."

Service	Realization method	Primary approach used
Confidentiality	Content encryption	Symmetric (content) + asymmetric (session-key protection)
Authentication/non-repudiation	Private-key digital signature → public-key verification	Asymmetric
Integrity	Hash (SHA-256) + signature, or HMAC	Asymmetric/symmetric

One point to note here is that "encrypting" with a public key and "signing" with a private key go in opposite directions. Encryption for confidentiality is done with the receiver's public key (because only the receiver should be able to open it with their private key), while signing for authentication and non-repudiation is done with the sender's private key (because anyone should be able to verify it with the sender's public key). Confusing this directionality leads to the design error of "encrypting but letting anyone open it," so in a professional engineer's answer it is important to clearly state which key is used for which purpose.

RSA vs ECC — Different Choices Even Within Asymmetric

Even within the same asymmetric family, RSA and ECC diverge in practical choice. RSA has a long history and broad implementation and compatibility, so it is still widely used in server certificates and legacy systems. ECC, by contrast, achieves equivalent strength with a much shorter key, so it is preferred in mobile, IoT, and large-scale traffic environments where certificate size, handshake latency, and power consumption matter. For example, ECC 256-bit offers strength comparable to RSA 3072-bit, so at the same security level ECC greatly reduces key and signature size. However, both approaches are vulnerable to quantum computers, so in the long term they share the common task of migrating to PQC.

4. Hybrid Approach (Digital Envelope) and Application Procedure

Symmetric encryption is fast but key distribution is hard, while asymmetric encryption makes key distribution easy but is slow. Because the two weaknesses are offset exactly by each other's strengths, combining them makes possible a design that "distributes keys quickly yet securely."

The representative design that fills each approach's limits with the other is the digital envelope. For each session the sender generates a random session key (symmetric) to rapidly encrypt the large content, encrypts only that session key with the receiver's public key (asymmetric), and sends it together with the ciphertext. The receiver recovers the session key with their own private key and then decrypts the content. This way, the slow asymmetric operation is applied only to the small session key and the fast symmetric operation to the large content, solving performance and key distribution simultaneously.

sequenceDiagram
  participant S as Sender
  participant R as Receiver
  S->>S: Generate session key (symmetric)
  S->>S: Encrypt content with session key
  S->>S: Encrypt session key with R's public key
  S->>R: Send ciphertext + encrypted session key
  R->>R: Recover session key with private key
  R->>R: Decrypt content with session key

There is a clear reason to generate a new session key each time. If the same session key were reused, a single key leak would bring down all past and future communications, and the large volume of data encrypted with the same key would become a target for statistical attacks. Using an independent ephemeral key per session confines the damage to that session even if one is exposed. This principle is also the foundation of the forward secrecy discussed later.

This structure is shared by the TLS handshake, S/MIME email encryption, and disk/document encryption solutions. For example, when connecting over HTTPS the browser securely agrees on a symmetric session key with the server certificate's public key (or ECDHE key exchange), and then the actual web traffic is exchanged with a symmetric cipher such as AES-GCM. In a single connection the public-key operation happens only at the handshake moment, and afterward tens of MB of pages and video are all handled symmetrically, so there is almost no performance degradation.

Modern TLS 1.3 goes one step further: instead of "delivering the session key as-is" with RSA, it uses ECDHE key exchange with ephemeral key pairs per session to secure forward secrecy. That is, even if the server's long-term private key is leaked in the future, traffic captured in the past cannot be decrypted. This is an evolution that overcomes the limitation of the classical digital envelope ("wrapping the session key with a public key and sending it") — that a long-term key leak exposes everything in the past.

Concrete Application Cases

E-commerce payment: Card companies and PG firms protect communication with merchants over TLS and additionally store sensitive card numbers with tokenization and symmetric encryption. The public key is used for payment-server identity proof and session-key agreement, while the symmetric key encrypts the actual transaction data.
Messenger end-to-end encryption (E2EE): Leading messengers agree on a session key with each user device's public key (asymmetric) and encrypt the actual messages and media symmetrically. Not even the server can see the content, so it is protected even if the central server is breached.
Disk/DB encryption (TDE): Large stored data must, for performance, be encrypted symmetrically (AES-256), while that data encryption key (DEK) is in turn wrapped by a master key (KEK) in a key-layering (envelope encryption) structure. This applies the digital-envelope concept to the storage domain.

5. Deep Dive — Trends in Post-Quantum Cryptography (PQC) Transition

The most important recent change is the quantum-computer threat and the transition to PQC (Post-Quantum Cryptography). Shor's algorithm, running on a sufficiently large quantum computer, can solve integer factorization and discrete logarithms in polynomial time, fundamentally neutralizing today's RSA, ECC, and DH. Symmetric encryption is sped up in search by Grover's algorithm, but doubling the key length (e.g., AES-256) maintains security, so the impact is relatively small. Therefore the heart of the threat is the public-key domain.

In particular, the "Harvest Now, Decrypt Later" attack is a practical risk. If an attacker stores ciphertext now and decrypts it once quantum computers are commercialized, data that must be kept secret for a long time (medical, state secrets, finance) will be exposed in the future. In other words, the judgment that "there are no quantum computers yet, so it's fine" does not hold for long-term confidential data.

Accordingly, the U.S. NIST finalized its PQC standards in August 2024. Representative ones are FIPS 203 (ML-KEM, based on CRYSTALS-Kyber) for key encapsulation, FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium) for digital signatures, and the hash-based signature FIPS 205 (SLH-DSA, based on SPHINCS+), most of which rest their security on lattice-based hard problems. For practical transition, a hybrid approach that uses the existing algorithms and PQC together, migrating gradually, is recommended, and domestically a PQC transition roadmap and a quantum-resistance validation framework are being pursued under KISA's leadership. In a professional engineer's answer, organizing it as the strategic flow "secure crypto-agility → identify crypto assets → apply hybrid → phased full transition" is persuasive.

The transition is not simple because cryptography is deeply intertwined with applications, protocols, hardware, and certificate frameworks. PQC algorithms have large key and signature sizes that affect network bandwidth, storage space, and handshake latency, and legacy equipment and embedded systems have long replacement cycles, so the coexistence period reaches several years. Therefore an organization should first conduct a comprehensive survey of where and which cryptography is used (crypto-asset inventory), abstract the algorithms so they can be swapped easily by configuration, and take a phased approach that prioritizes transitioning high-risk assets (long-term confidential, externally exposed) first.

6. Considerations and Implications

Key management is the security level itself: No matter how strong the algorithm, if the key leaks it is meaningless. Protect keys with an HSM (hardware security module) or KMS, and control the key lifecycle spanning generation, distribution, use, storage, renewal, and destruction. To limit damage when a key leaks, a design that uses a fresh session key each time and forward secrecy are important.
Choosing secure key lengths and algorithms: Maintain AES-256 and RSA-2048/3072 or higher to anticipate improvements in computing performance, and in resource-constrained environments adopt ECC, which delivers equivalent strength with a shorter key. Immediately exclude vulnerable and deprecated algorithms such as DES, MD5, and SHA-1.
Establish a PQC transition roadmap proactively: Considering the "Harvest Now, Decrypt Later" threat, proactively transition long-term confidential data first to a hybrid based on NIST standards (ML-KEM/ML-DSA), and embed into the architecture crypto-agility that allows algorithms to be swapped easily.
Requirement- and regulation-based design: Combine symmetric, asymmetric, and hybrid according to whether only confidentiality is needed or non-repudiation as well. Domestic systems must also consider requirements to use domestic algorithms such as SEED, ARIA, and LEA, as well as compliance with regulations such as the Personal Information Protection Act and the Digital Signature Act.
Beware of implementation and operational pitfalls: Even with secure algorithms, implementation flaws such as degraded random-number quality, padding oracles, skipped certificate validation, and session-key reuse become real leakage paths. Use validated cryptographic libraries and standard modes (authenticated encryption such as AES-GCM), and avoid roll-your-own crypto.
Balancing performance, regulation, and interoperability: Finance and the public sector have strict throughput (TPS) and latency requirements, so amortize the cost of public-key operations with hardware acceleration, session reuse, and connection pooling. At the same time, the design must address regulatory compliance such as mandatory domestic algorithms, personal-information encryption notices, and digital-signature validity, together with algorithm and certificate interoperability with external systems.

In sum, cryptographic design from a professional engineer's standpoint should be approached not as an either/or of "symmetric or asymmetric," but as holistic architecture design that combines both approaches in the right places by comprehensively weighing security requirements (confidentiality, integrity, authentication, non-repudiation) against performance, regulatory, and lifecycle constraints, backs them with a key-management framework, and embeds the agility to prepare for the quantum era.

References

NIST, Post-Quantum Cryptography Standardization (FIPS 203/204/205): https://csrc.nist.gov/projects/post-quantum-cryptography
NIST SP 800-57, Recommendation for Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc8446
KISA Cryptography Use Promotion (domestic ciphers SEED/ARIA/LEA): https://seed.kisa.or.kr

In one line: Symmetric encryption is fast with a single secret key but hard to distribute keys, while asymmetric encryption favors key distribution and digital signatures with public/private keys but is slow; in practice they are combined as a hybrid — like the digital envelope and TLS — that protects the session key with asymmetric encryption and encrypts the content with symmetric encryption, and to prepare for the quantum-computer threat a transition based on NIST PQC (ML-KEM/ML-DSA) must be readied proactively.