Symmetric and Asymmetric Keys: How the Architecture Has Shifted

The traditional framing is well known: use symmetric keys for bulk encryption because they are fast, and use asymmetric keys for key exchange or signatures because they provide mathematical trust without requiring a shared secret.

That framing is still correct in principle. What has changed is almost everything around it.

The architecture of key management, key distribution, key rotation, and key isolation has shifted substantially in recent years. Cloud key management services, zero-trust network design, workload identity, and the approaching post-quantum transition have all forced architects to think about cryptographic keys in ways that go well beyond the AES-versus-RSA comparison.

This article traces how that shift has played out and where AWS fits into it.

The Traditional Model

In the traditional model, symmetric and asymmetric keys had well-understood and largely separate roles:

• Symmetric keys (AES, ChaCha20): fast, used for encrypting data in bulk, but require the communicating parties to share the same secret somehow.
• Asymmetric keys (RSA, ECDSA, ECDH): slower, used for key exchange or digital signatures, but the private key never leaves the originator.

The combination of these two - use asymmetric keys to establish trust and exchange a symmetric key, then use that symmetric key for bulk encryption - is called hybrid encryption. TLS has used this approach for decades.

For most application developers, the practical implication was simple: TLS handled key exchange transparently, and the application layer dealt only with symmetric secrets such as database passwords, API keys, and session tokens.

That separation has collapsed.

What Changed

1. Hybrid Encryption Is Now the Default Everywhere

TLS 1.3, finalised in 2018 and now dominant in production traffic, made a significant architectural decision: it mandates ephemeral key exchange (ECDHE) for every session. There is no longer an option to use RSA for direct key transport. Every TLS 1.3 session derives a fresh symmetric session key from an ephemeral asymmetric exchange and then immediately discards the asymmetric material.

The consequence is forward secrecy by default. If an attacker records encrypted traffic today and later compromises the server’s private key, they cannot decrypt historical sessions because the session keys were never persisted.

AWS services implement this fully. ALB and CloudFront security policies that restrict to TLS 1.3 enforce ECDHE automatically. The asymmetric key in ACM is used only for authentication, not for key transport.

The lesson for architects: the choice of asymmetric algorithm now matters even for services that do not appear to use asymmetric cryptography directly. Your load balancer’s certificate policy is a cryptographic architecture decision.

2. Envelope Encryption Has Become the Standard Pattern

The most consequential architectural shift at the application layer is the universal adoption of envelope encryption.

The model is:

1. A Data Encryption Key (DEK) is generated locally and used to encrypt the actual data.
2. The DEK itself is then encrypted using a Key Encryption Key (KEK), which is stored and managed separately.
3. Only the encrypted DEK is stored alongside the ciphertext.

flowchart TD
    A([Plaintext Data]) -->|encrypt with DEK| B([Ciphertext])
    C([DEK]) -->|encrypt with KEK| D([Encrypted DEK])
    B --> E[(Stored Together)]
    D --> E

    style A fill:#1e3a5f,color:#93c5fd
    style B fill:#3f3f46,color:#e4e4e7
    style C fill:#7c2d12,color:#fdba74
    style D fill:#3f3f46,color:#e4e4e7
    style E fill:#14532d,color:#86efac

This pattern cleanly separates key management from data management. The KEK never touches the data directly, so it can be rotated, audited, or revoked without re-encrypting the entire dataset.

AWS KMS is built entirely around this pattern. When S3 uses SSE-KMS, it calls KMS to generate a data key, uses that key to encrypt the object, and stores the encrypted DEK alongside the object metadata. The KMS customer managed key (CMK) never leaves the AWS KMS hardware - it only ever encrypts and decrypts smaller DEKs.

The same pattern applies to EBS volume encryption, RDS encryption, Secrets Manager, and practically every AWS service that encrypts data at rest.

The CMK itself is a symmetric AES-256 key. But the key hierarchy creates an implicit authentication boundary: only principals with kms:Decrypt permission can recover the DEK. The cryptographic model is symmetric throughout, but the access control model behaves like asymmetric cryptography - possession of the CMK is separated from possession of the data.

3. Asymmetric Keys Have Moved into Identity and Trust

The most significant expansion of asymmetric key usage in recent years is not in data encryption. It is in workload identity.

A decade ago, service-to-service authentication usually meant sharing a long-lived symmetric secret: an API key, a database password in an environment variable, or a shared HMAC secret. Both sides held the same secret. Compromise of either side compromised the credential entirely.

The modern approach uses asymmetric keys instead. A service proves its identity by presenting a token signed with a private key. The verifier checks the signature against a published public key without ever needing to know the private key. The private key never leaves the issuer.

sequenceDiagram
    participant Service as Workload
    participant IdP as Identity Provider
    participant API as Downstream API

    Service->>IdP: Request token
    IdP-->>Service: Signed JWT (asymmetric signature)
    Service->>API: Request + JWT
    API->>API: Verify JWT signature against public key
    API-->>Service: Response

AWS implements this pattern across several services:

• IAM OIDC: EKS pods and GitHub Actions workflows assume IAM roles by presenting OIDC tokens signed by the identity provider. IAM verifies the signature using the provider’s published public key. No shared secret is exchanged between the workload and IAM.
• EKS Pod Identity: Assigns IAM roles directly to Kubernetes service accounts using short-lived asymmetrically signed tokens, replacing the need for static credentials in pods.
• ACM Private CA: Internal services authenticate using certificates issued by a private certificate authority. Trust is based on the asymmetric key pair in the certificate, not a password.
• AWS STS AssumeRoleWithWebIdentity: Accepts OIDC tokens and issues short-lived AWS credentials, bridging external identity providers into the AWS trust model.

The broader architectural consequence is the elimination of long-lived symmetric secrets from service-to-service trust paths. A compromised static API key grants full access immediately and indefinitely. A compromised private key requires the attacker to use it for signing, and the token’s short lifetime limits the blast radius to minutes.

4. Key Isolation Has Become a First-Class Requirement

In older designs, it was common to use a single encryption key across multiple services or environments. The key was treated like a master password: stored securely and used broadly.

Modern zero-trust design rejects this. Each service, environment, tenant, or data classification level should have its own key hierarchy. A compromise of one key should not compromise all data.

AWS KMS makes this operationally practical with customer managed keys (CMKs). Each CMK can carry its own key policy, its own rotation schedule, and its own audit trail via CloudTrail. A KMS key grant can give a specific Lambda function or ECS task access to a specific key without that access propagating to any other service.

flowchart LR
    A([Service A]) -->|kms:Decrypt| B([CMK A])
    C([Service B]) -->|kms:Decrypt| D([CMK B])
    E([Service C]) -->|kms:Decrypt| F([CMK C])
    B --> G[(Data Store A)]
    D --> H[(Data Store B)]
    F --> I[(Data Store C)]

    style A fill:#1e3a5f,color:#93c5fd
    style C fill:#1e3a5f,color:#93c5fd
    style E fill:#1e3a5f,color:#93c5fd
    style B fill:#7c2d12,color:#fdba74
    style D fill:#7c2d12,color:#fdba74
    style F fill:#7c2d12,color:#fdba74
    style G fill:#3f3f46,color:#e4e4e7
    style H fill:#3f3f46,color:#e4e4e7
    style I fill:#3f3f46,color:#e4e4e7

The result is a key topology that mirrors the service topology. A key breach is bounded to the blast radius of one service, not the entire system.

For workloads requiring hardware-level isolation, AWS CloudHSM provides a dedicated Hardware Security Module (HSM) within the customer’s VPC. Keys are generated inside the hardware and never exported in plaintext. This is the standard in regulated industries where FIPS 140-2 Level 3 validation is required by compliance frameworks.

5. The Post-Quantum Transition Is Underway

The most structurally significant shift on the horizon is the migration from classical asymmetric cryptography (RSA, ECC) to post-quantum algorithms.

In 2024, NIST finalised three post-quantum cryptography standards:

• ML-KEM (from CRYSTALS-Kyber): for key encapsulation and key exchange - the post-quantum replacement for ECDH.
• ML-DSA (from CRYSTALS-Dilithium): for digital signatures - the post-quantum replacement for ECDSA.
• SLH-DSA (from SPHINCS+): a stateless hash-based signature scheme offered as a conservative alternative.

These are not drop-in replacements. ML-KEM public keys are significantly larger than ECDH public keys. ML-DSA signatures are larger than ECDSA signatures. The storage and bandwidth implications affect protocol design.

The concern driving this transition is harvest now, decrypt later: an adversary can record encrypted traffic today and decrypt it once a sufficiently powerful quantum computer exists. For data with a long confidentiality horizon, this is already a credible threat.

AWS has begun integrating post-quantum hybrid key exchange in TLS connections to KMS, Secrets Manager, and S3. The hybrid approach combines a classical ECDHE exchange with a post-quantum ML-KEM exchange so that security holds even if one of the two algorithms is later broken.

Architects should note: this is an asymmetric-specific problem. Symmetric AES-256 is considered post-quantum secure with no change required. The migration burden falls entirely on the asymmetric side of the stack.

AWS Key Architecture at a Glance

The Architectural Takeaways

Symmetric keys encrypt data; asymmetric keys establish trust. This has always been roughly true, but the split is now architecturally explicit. AWS KMS manages symmetric keys for bulk encryption. ACM, IAM OIDC, and Private CA manage asymmetric keys for identity and authentication. These two concerns are handled by separate services with separate operational models.

Envelope encryption makes key rotation safe. Because the DEK is short-lived and the CMK only ever encrypts DEKs rather than data directly, rotating the CMK means re-encrypting only the DEKs, not the full dataset. This makes annual or on-demand rotation practical even for multi-terabyte data stores.

Long-lived symmetric secrets in service-to-service paths are an architectural smell. If a service authenticates to another using a static API key or shared password, that is a symmetric credential with no expiry, no audit trail, and a broad blast radius on compromise. The modern replacement is short-lived, asymmetrically signed tokens issued by an identity provider and verified against public keys.

The key hierarchy is a threat model. Where keys are stored, who can use them, what they encrypt, and how they rotate should map directly to the threat model. A single CMK for all services is the cryptographic equivalent of one password for every account. Per-service, per-environment key isolation is the baseline posture.

Post-quantum affects only the asymmetric side. AES-256 is safe. RSA and ECC key exchange are the migration target. Start by auditing where classical asymmetric key exchange is used, particularly in long-lived data scenarios, and plan the hybrid transition from there.

Closing Thought

Symmetric and asymmetric cryptography are not competing approaches. They have always been complementary, and modern architecture makes that complementarity explicit at every layer: symmetric AES for data at rest, asymmetric ECDHE for session key establishment, asymmetric signatures for workload identity, and a managed key hierarchy above all of it.

What has changed is the infrastructure built around that model. Cloud key management, hardware security modules, workload identity providers, and the post-quantum transition have together turned key architecture from a topic that lived inside a TLS terminator into a first-class architectural concern spanning every layer of the system.

The engineers who understand the distinction build systems that are easier to audit, safer to rotate, and better isolated when something eventually goes wrong.