H33-Key: Why Every Key in Your Infrastructure
Needs Post-Quantum Encryption

The Plaintext Key Problem

Every modern infrastructure runs on keys. Database connection strings contain passwords. SSH keys grant shell access to production servers. API tokens authorize requests to payment processors, cloud providers, and third-party services. TLS certificates terminate HTTPS connections. Service account credentials let microservices authenticate to each other. Crypto wallet private keys control millions in digital assets. Blockchain signing keys authorize smart contract transactions. These keys are the connective tissue of your entire stack, and almost everywhere you look, they sit in plaintext.

Open any .env file in any production deployment on earth. You will find lines like DATABASE_URL=postgres://admin:s3cr3tP@ss@db.prod.internal:5432/myapp. That password is a plaintext string stored on a filesystem. It is loaded into process memory at startup. It is often committed to version control, at least once, by accident. Even in organizations that use secrets managers — AWS Secrets Manager, HashiCorp Vault, Azure Key Vault — the key material is eventually decrypted and held in application memory for the lifetime of the process. The secrets manager protects the key at rest in its own storage. It does not protect the key after retrieval. The moment your application calls getSecretValue(), the key is plaintext in RAM, and it stays that way until the process terminates. A memory dump, a core file, a debugger attach, or a side-channel read on a shared-tenancy VM can extract it.

SSH keys are worse. Most organizations store SSH private keys in ~/.ssh/ on developer laptops and jump hosts. The private key file is protected by filesystem permissions and, sometimes, a passphrase. But the passphrase is typically cached by ssh-agent for the duration of the session, meaning the decrypted private key material sits in memory for hours or days. A stolen laptop, a compromised developer workstation, or a supply chain attack on an SSH client dependency gives an attacker persistent access to every server that trusts that key. The same pattern applies to TLS private keys sitting in /etc/ssl/, to Kubernetes service account tokens mounted as files in pods, and to API tokens stored in CI/CD environment variables that any pipeline contributor can read.

The problem is not that organizations are careless. The problem is structural. Classical key management architectures assume that the key, once decrypted for use, is safe in memory. That assumption was already questionable with Spectre, Meltdown, and Rowhammer. It becomes categorically false in a post-quantum world.

What H33-Key Is (and Is Not)

H33-Key is a transparent post-quantum key encryption layer. It is not a vault. It is not a secrets manager. It is not trying to replace HashiCorp Vault or AWS Secrets Manager or any other tool you already use to store and distribute secrets. Those tools solve the storage and access control problem. H33-Key solves a different problem entirely: it ensures that the key material itself is never stored or transmitted in a form that a quantum computer can retroactively decrypt.

The distinction matters. A secrets manager stores your database password and controls who can retrieve it. H33-Key wraps that password in a Kyber-1024 post-quantum envelope before it enters the secrets manager, and unwraps it only at the point of use, only for the minimum duration required. The secrets manager never holds plaintext key material. Your .env files never contain plaintext credentials. Your CI/CD pipelines never see raw tokens. Every key at every stage of its lifecycle — at rest in storage, in transit between systems, and in configuration files on disk — is wrapped in a lattice-based cryptographic envelope that no known classical or quantum algorithm can break.

H33-Key works with any key, in any format, stored anywhere. Database credentials. SSH private keys. TLS certificate private keys. API bearer tokens. OAuth client secrets. Kubernetes service account tokens. AWS access keys. Stripe secret keys. Twilio auth tokens. GitHub personal access tokens. Crypto wallet private keys. Blockchain signing keys. HD wallet seed phrases. If it is a string that grants access to something, H33-Key encrypts it with Kyber-1024 and gives you back an opaque ciphertext blob that you store in place of the original. When you need the key, you call decrypt, use the plaintext for the minimum required duration, and the key goes back to its encrypted form. The original plaintext never touches disk, never enters version control, and never sits in an environment variable.

How It Works: Kyber KEM + AES-GCM Hybrid

H33-Key uses a hybrid encryption scheme built on CRYSTALS-Kyber-1024 (NIST FIPS 203) key encapsulation and AES-256-GCM authenticated encryption. The architecture is straightforward and follows the standard KEM/DEM (Key Encapsulation Mechanism / Data Encapsulation Mechanism) paradigm that NIST recommends for post-quantum migration.

When you encrypt a key, H33-Key generates a fresh Kyber-1024 KEM encapsulation against your public key. This produces a 256-bit shared secret and an approximately 1,568-byte ciphertext (the encapsulated key). The shared secret is used as the AES-256-GCM key to encrypt the actual key material. The encrypted output is the Kyber ciphertext concatenated with the AES-GCM ciphertext, nonce, and authentication tag. The Kyber ciphertext can only be decapsulated by the holder of the corresponding Kyber private key. The AES-GCM ciphertext can only be decrypted with the shared secret derived from that decapsulation. Even if an attacker obtains the encrypted blob, they need to solve the Module Learning With Errors (MLWE) problem to extract the shared secret — a problem that remains hard for both classical and quantum computers under Kyber-1024 parameters.

The hybrid approach is deliberate. Kyber provides the post-quantum security guarantee. AES-256-GCM provides authenticated encryption with associated data (AEAD), ensuring both confidentiality and integrity of the wrapped key material. The combination means that an attacker must break both Kyber-1024 and AES-256 to recover the original key. In practice, Kyber alone is sufficient. But defense in depth is not optional when you are protecting the keys that protect everything else.

const response = await fetch('https://api.h33.ai/v1/key/encrypt', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer h33_sk_live_...',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    "key_material": "postgres://admin:s3cr3tP@ss@db.prod:5432/myapp",
    "tier": "key-1",
    "label": "prod-database-primary",
    "metadata": { "service": "api-server", "env": "production" }
  })
});

const result = await response.json();
// {
//   "key_id": "hk_9f3a2b71e4c8",
//   "ciphertext": "a3f8c2...b291e4",
//   "kem": "CRYSTALS-Kyber-1024",
//   "dem": "AES-256-GCM",
//   "integrity": "HMAC-SHA3-256",
//   "latency_ms": 0.47
// }

The ciphertext returned by the encrypt call is what you store. In your secrets manager. In your .env file. In your Kubernetes secret. In your CI/CD pipeline variables. Anywhere you previously stored the plaintext key, you now store the H33-Key ciphertext. When your application needs the actual credential, it calls the decrypt endpoint:

curl -X POST https://api.h33.ai/v1/key/decrypt \
  -H "Authorization: Bearer h33_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "key_id": "hk_9f3a2b71e4c8",
    "ciphertext": "a3f8c2...b291e4",
    "purpose": "database_connect",
    "ttl_seconds": 30
  }'

# Response:
# {
#   "key_material": "postgres://admin:s3cr3tP@ss@db.prod:5432/myapp",
#   "decrypted_at": "2026-03-09T14:22:07.841Z",
#   "expires_at": "2026-03-09T14:22:37.841Z",
#   "provenance": "dilithium-verified",
#   "latency_ms": 0.52
# }

The ttl_seconds parameter is not cosmetic. H33-Key's decrypt response includes a cryptographic expiration marker. Client SDKs automatically zero out the decrypted material from memory when the TTL expires. This is not garbage collection — it is explicit, immediate zeroing of the memory region holding the plaintext key. The window during which plaintext key material exists in your application's memory shrinks from "the entire process lifetime" to "30 seconds" (or whatever TTL you set). That is a categorically different threat surface.

Use Cases: Every Key, Everywhere

The universality of H33-Key is the point. It is not designed for a single category of secrets. It is designed for every key that exists in your infrastructure, regardless of format, storage location, or access pattern.

Database credentials. Connection strings for PostgreSQL, MySQL, MongoDB, Redis, and every other data store in your stack. Instead of storing DATABASE_URL=postgres://admin:password@host/db in an environment variable, you store the H33-Key ciphertext. Your application decrypts at startup, holds the plaintext for the minimum duration needed to establish the connection pool, and the plaintext is zeroed. If an attacker dumps your environment variables or reads your config files, they get Kyber-encrypted blobs that are computationally worthless.

SSH keys. Private keys for server access, Git operations, and infrastructure automation. H33-Key wraps the PEM-encoded private key in a Kyber envelope. The encrypted blob is stored in ~/.ssh/ instead of the raw private key. An ssh-agent integration decrypts the key for individual authentication events and zeroes it immediately after. A stolen laptop no longer means compromised server access, because the SSH private key on disk is post-quantum encrypted and the attacker cannot decapsulate the Kyber ciphertext even with unlimited classical computing resources.

API tokens and service credentials. Stripe secret keys, AWS access key pairs, Twilio auth tokens, GitHub tokens, OAuth client secrets — every third-party credential that your application uses to authenticate to external services. These tokens are high-value targets because they often grant broad access with no IP restriction or MFA requirement. Wrapping them in Kyber envelopes means that a compromised CI/CD pipeline, a leaked .env file, or a dependency supply chain attack does not directly expose the token. The attacker gets ciphertext that requires a Kyber private key they do not possess.

TLS certificate private keys. The private keys for your HTTPS certificates, your mTLS client certificates, and your internal CA signing keys. These keys are typically stored on disk in /etc/ssl/ or in a certificate manager. If an attacker obtains the TLS private key, they can impersonate your server, decrypt captured traffic (for non-PFS cipher suites), and issue fraudulent certificates from your internal CA. H33-Key wraps these keys so that they are only decrypted during TLS handshake operations. The private key material's plaintext lifetime drops from "forever on disk" to "milliseconds during handshake."

Crypto wallet and blockchain signing keys. Private keys for Ethereum wallets, Solana keypairs, Bitcoin HD wallet seeds, and smart contract signing keys represent some of the highest-value secrets in any organization. A single compromised wallet private key can drain millions in minutes with no recourse — blockchain transactions are irreversible. Hot wallets are especially vulnerable: the private key must be available for signing, which means it sits in memory or on disk in a form that can be exfiltrated. H33-Key wraps wallet private keys in Kyber-1024 envelopes. The key is decrypted only for the duration of a signing operation, then immediately zeroed. For custodial operations, Key-3's threshold decryption adds k-of-n approval — no single operator can unilaterally access a signing key, and every decryption event carries a Dilithium-signed provenance chain that is admissible for audit and compliance. This is hardware-security-module-grade protection without the hardware, and it is quantum-safe from day one.

Setup: From Zero to Encrypted in Five Minutes

H33-Key is designed for zero-friction adoption. There is no infrastructure to deploy, no agents to install, and no migration project to plan. You get an API key, make one encrypt call, and your first key is post-quantum protected.

Step 1: Get your API key. Sign up at h33.ai/pricing, select the Key tab, and choose a unit pack. Your API key is provisioned instantly. No credit card required for the free tier.

Step 2: Encrypt your first key. Make a single API call to POST /v1/key/encrypt with the key material you want to protect. You get back a ciphertext blob and a key ID. Store the ciphertext wherever the plaintext key used to live — your .env file, your database column, your CI/CD variable.

Step 3: Decrypt at point of use. When your application needs the key, call POST /v1/key/decrypt with the key ID or ciphertext. Set a TTL so the plaintext is automatically zeroed from memory after use. Your application code changes are minimal — replace the direct config read with a decrypt call at startup.

Step 4: Scale with SDKs. For production deployments, use the H33-Key SDK for your language (Node.js, Python, Go, Rust). The SDK wraps the API calls, handles caching of decrypted material within TTL windows, and provides middleware for popular frameworks. A Node.js Express app, for example, replaces process.env.DATABASE_URL with await h33key.decrypt('prod-database-primary'). A Docker sidecar option is available for environments where you cannot modify application code — the sidecar intercepts environment variable reads and transparently decrypts.

Step 5: Enable advanced tiers. Once your keys are encrypted (Key-0), upgrading to higher tiers is a configuration change, not a re-architecture. Enable HMAC integrity checks (Key-1), add envelope rotation policies (Key-2), or configure threshold approval workflows (Key-3) — all through the API or dashboard. Your encrypted keys stay in place. The protection layer evolves around them.

Sub-Millisecond Performance

Post-quantum cryptography has a reputation for being slow. That reputation was earned in 2022 and has been wrong ever since. CRYSTALS-Kyber-1024, the KEM at the core of H33-Key, is one of the fastest public-key operations in any cryptographic library, classical or post-quantum. Kyber's key generation, encapsulation, and decapsulation are based on matrix-vector multiplications over polynomial rings, which map efficiently onto modern CPU architectures with Number Theoretic Transform (NTT) acceleration.

On H33's production infrastructure (Graviton4 c8g.metal-48xl), a full H33-Key encrypt operation — Kyber-1024 encapsulation, AES-256-GCM encryption of the key material, and HMAC-SHA3-256 integrity tag (Key-1 tier) — completes in approximately 0.47 milliseconds. Decrypt (Kyber decapsulation + AES-GCM decryption + HMAC verification) completes in approximately 0.52 milliseconds. These are not microbenchmark numbers. These are end-to-end latencies including network overhead, API authentication, and audit logging.

For context, a typical AWS Secrets Manager GetSecretValue call has a p50 latency of 10–50 milliseconds depending on region and load. An HashiCorp Vault read operation runs 5–20 milliseconds. Azure Key Vault's decrypt operation averages 15–30 milliseconds. H33-Key's encrypt and decrypt operations are 10x to 60x faster than the secrets management tools most organizations already use — and those tools are not providing post-quantum protection. You are not adding latency to your secrets pipeline by adopting H33-Key. You are likely reducing it while simultaneously upgrading from classical to post-quantum security.

The Four Tiers

H33-Key is structured as four progressive tiers, each adding cryptographic guarantees on top of the previous level. Every tier uses Kyber-1024 as the post-quantum KEM. There is no "classical only" option. The question is not whether your keys get post-quantum protection — they do, at every tier — but what additional integrity, wrapping, and access control properties you need.

Key-0 is pure Kyber-1024 encryption and decryption. Your key material goes in plaintext, comes back as an opaque ciphertext blob, and is never stored in plaintext anywhere in the H33 system. At 3 credits per operation, this is the lowest-cost post-quantum key encryption available anywhere. It is ideal for environment variables, config file values, and any secret that simply needs to not be plaintext on disk or in memory.

Key-1 adds HMAC-SHA3-256 integrity verification on top of the Kyber encryption. Every encrypted payload includes a SHA3-based message authentication code that detects any tampering with the ciphertext. If an attacker modifies even a single bit of the encrypted blob — in storage, in transit, or in a man-in-the-middle scenario — the integrity check fails and decryption is refused. This is critical for database credentials and API tokens where a corrupted credential causes silent authentication failures that are difficult to debug. At 8 credits per operation, Key-1 is the recommended tier for most production secrets.

Key-2 introduces key wrapping: the ability to wrap an existing key under a post-quantum envelope without re-encrypting the data the key protects. This is the tier designed for key rotation workflows. When you need to rotate the encryption envelope — because of a policy requirement, a personnel change, or a suspected compromise — Key-2 rotates the outer Kyber wrapper without requiring the underlying key material to be re-issued. You rotate the envelope in seconds. The underlying SSH key, TLS certificate, or signing key remains unchanged. This eliminates the most painful operational burden in key management: coordinating key rotation across every system that uses a credential.

Key-3 is the maximum security tier. It adds threshold decryption, meaning the encrypted key cannot be decrypted by any single party. You configure a k-of-n threshold — for example, 3-of-5 — and decryption requires k authorized participants to each provide their share. No single administrator, no single compromised workstation, and no single insider threat can decrypt the key material alone. Additionally, Key-3 includes a Dilithium-signed provenance chain: every encrypt, decrypt, wrap, and rotation event is recorded with a FIPS 204 post-quantum digital signature, creating a tamper-proof audit trail of every operation performed on the key. This tier is designed for root CA private keys, master database encryption keys, and any credential where unauthorized decryption constitutes an existential organizational risk.

How H33-Key Compares

The key management market is not empty. AWS KMS, HashiCorp Vault Transit, Azure Key Vault, and Google Cloud KMS all offer key wrapping and encryption capabilities. The question is not whether alternatives exist, but whether any of them provide post-quantum security, sub-millisecond latency, and transparent integration with your existing secrets infrastructure. The answer, as of March 2026, is that none of them do.

AWS KMS uses AES-256 for symmetric operations and RSA or ECC for asymmetric operations. There is no post-quantum KEM option. AWS has published research papers on post-quantum TLS but has not shipped post-quantum key wrapping in KMS. Encrypt/decrypt latency runs 5–15ms (p50) due to network round-trips to the KMS endpoint and HSM-backed operations. AWS KMS is an excellent access control and audit layer. It is not a post-quantum encryption layer.

HashiCorp Vault Transit provides encryption-as-a-service with AES-256-GCM, ChaCha20-Poly1305, RSA, and ECDSA. Vault's transit engine encrypts data in transit and at rest, but all operations use classical cryptography. Post-quantum algorithms are not available in any Vault release as of this writing. Vault transit operations run 5–20ms depending on deployment topology (self-hosted vs. HCP Vault). Vault solves secrets management, access policies, and dynamic credentials brilliantly. It does not solve the harvest-now-decrypt-later problem because it does not offer post-quantum encryption.

Azure Key Vault supports RSA and EC key operations with HSM backing. Like AWS KMS, it provides robust access control and audit logging. Like AWS KMS, it uses exclusively classical cryptography. Decrypt latency runs 15–30ms for RSA operations. Azure has announced post-quantum research initiatives but has not shipped production PQ key operations.

H33-Key is not competing with these tools on access control, policy management, or secrets distribution. Those are solved problems. H33-Key sits underneath them as the encryption layer. You continue using Vault for secrets management. You continue using AWS KMS for access policies. But before a key enters any of those systems, H33-Key wraps it in a Kyber-1024 envelope. And when a key is retrieved from any of those systems, H33-Key unwraps it at the point of use with a sub-millisecond decapsulation. The existing tools become the access control and distribution layer. H33-Key becomes the cryptographic protection layer. They are complementary, not competitive.

Zero-Exposure Infrastructure: H33-Gateway

Every secrets manager on the market decrypts the key before handing it to you. AWS KMS decrypts your data key and returns plaintext to your application. Vault Transit decrypts and returns plaintext. Azure Key Vault decrypts and returns plaintext. The moment that plaintext key exists in your application’s memory, your infrastructure, your logs, your process table — it is exposed. If your server is compromised, the key is compromised. If your container is snapshotted, the key is in the snapshot. If your memory is dumped, the key is in the dump.

H33-Gateway eliminates this moment entirely.

Instead of decrypting a key and handing it to your application to use, H33-Gateway acts as a TEE (Trusted Execution Environment) proxy. Your application sends the encrypted key ID and the API request it wants to make. H33-Gateway decrypts the key inside a secure enclave (AWS Nitro Enclaves), makes the API call to Stripe, AWS, Twilio, or whatever third-party service your key authenticates against, zeroes the plaintext from enclave memory, and returns only the API response to your application. Your infrastructure never sees, touches, or stores the plaintext key. The SOC 2 auditor asks “where does the plaintext key exist in your infrastructure?” and the answer is “nowhere.”

Consider a hospital running Epic EHR integrations. The API credential that authenticates against Epic’s FHIR endpoints sits in plaintext in a Jenkins environment variable. Forty engineers have read access to that Jenkins instance. With H33-Gateway, that credential is encrypted in place. When the integration service needs to call Epic, it sends the encrypted key ID and the FHIR request to H33-Gateway. The gateway decrypts inside the enclave, makes the call, returns the response. The Jenkins variable contains only ciphertext. The forty engineers can read it all day — it is cryptographically useless without the Kyber decapsulation key they do not possess.

Consider a bank where Stripe payment processing keys sit in a config file that forty engineers can read. With H33-Gateway, the charge request goes through the TEE proxy. The Stripe key never exists in the bank’s infrastructure. Period.

H33-Gateway works with any third-party API today. No integration required from the third party. No SDK they need to install. No partnership agreement. If your application can make an HTTP request, H33-Gateway can proxy it through a secure enclave. This is the primary advanced offering because it solves the zero-exposure problem immediately, for every customer, without any ecosystem dependencies.

The Ecosystem Vision: Key-FHE

H33-Gateway eliminates plaintext from your infrastructure by decrypting inside a TEE. But the key still gets decrypted somewhere — inside the enclave. For most organizations, this is more than sufficient. A Nitro Enclave with remote attestation is a dramatically smaller attack surface than a Jenkins environment variable.

But what if the key never had to be decrypted at all?

Key-FHE uses BFV fully homomorphic encryption to verify that an encrypted key matches a registered key — without ever decrypting either one. The service that accepts the key integrates the H33-Key SDK. When a client presents an encrypted API key, the service runs an FHE comparison against the enrolled encrypted key. The comparison produces a match/no-match result. At no point does any party — not the client, not the service, not H33 — see the plaintext key. It is cryptographic verification without decryption.

This requires both sides to integrate. The service accepting the key must embed the H33-Key server SDK. The client presenting the key must encrypt it with H33-Key. When both sides are integrated, the key is never decrypted anywhere, ever. This is the long-term ecosystem vision: a world where API keys, database credentials, and signing keys are verified homomorphically, and plaintext key material is a relic of a less sophisticated era.

Key-FHE is positioned honestly as the future. It requires partner adoption — GitLab integrating the SDK to accept encrypted deploy tokens, AWS integrating it for IAM credentials, Stripe integrating it for payment keys. That adoption cycle is measured in quarters, not days. But when it arrives, the cryptographic guarantee is absolute: the key is never decrypted by anyone.

Revocation & Key Lifecycle

If the key is encrypted everywhere and no one ever decrypts it (in the FHE model) or decryption happens only inside a TEE (in the Gateway model), how does the system know to stop accepting the old ciphertext when a key is compromised or rotated?

H33-Key maintains a server-side key registry. Every encrypted key receives a unique identifier (hk_*). This registry is the revocation authority, analogous to certificate revocation lists (CRL) or OCSP in the X.509 PKI world, but applied to symmetric and asymmetric key material.

• Revoke: Mark a key ID as revoked. All future decrypt, verify, proxy, and FHE operations for that ID return REVOKED. The ciphertext still exists wherever it was stored, but H33 refuses to operate on it.
• Rotate: Generate a new Kyber envelope for new key material. A new key ID is issued. The old ID is marked ROTATED with a configurable grace period (during which both old and new IDs work). After grace period expiry, the old ID is automatically revoked.
• Status check: GET /v1/key/status/:id returns active, rotated, or revoked.

For Gateway operations: before proxying a request, the registry is checked. Revoked keys are never decrypted, even inside the TEE. For FHE operations: before the FHE comparison runs, the registry is checked. Revoked keys fail before the compute even starts. This ensures that even if an attacker obtains the ciphertext, they cannot use it to authenticate or proxy requests once the key ID is revoked.

Pricing That Scales

H33-Key operates on the same credit-based pricing model as the rest of the H33 platform. You purchase units in volume tiers, and each H33-Key operation consumes the number of units corresponding to its tier.

At enterprise scale (5M+ units), a Key-1 encrypt or decrypt operation costs $0.048. A Key-0 operation costs $0.018. To put that in perspective: the average cost of a data breach involving stolen credentials was $4.5 million in 2025 (IBM Cost of a Data Breach Report). The annual cost of wrapping every credential in a 500-service microservice architecture with Key-1 at enterprise pricing is less than the legal retainer for a single breach investigation. The economics are not close.

Getting Started

H33-Key is available today through the same API key and credential system as the rest of the H33 platform. Provisioning takes less than 60 seconds. There is no separate product signup, no sales call requirement, and no minimum commitment.

Start with Key-0 to encrypt your most critical credentials — database passwords, API tokens, and anything currently sitting in plaintext in environment variables. Upgrade to Key-1 when you need integrity verification to catch tampering. Move to Key-2 when your key rotation workflows need envelope rotation without credential re-issuance. Adopt Key-3 when your root keys and CA certificates require threshold decryption and provenance chains. Deploy H33-Gateway when your infrastructure should never touch plaintext keys at all — the TEE proxy handles API calls on your behalf. Integrate Key-FHE when both sides support it for the ultimate guarantee: the key is never decrypted by anyone.

• Get your API key — /pricing
• API documentation — /docs/api
• Pricing details — /pricing

Every key in your infrastructure is a liability. Database passwords in environment variables. SSH keys on developer laptops. API tokens in CI/CD pipelines. TLS private keys on disk. Every one of them is stored in a form that a sufficiently powerful quantum computer will eventually be able to extract from intercepted ciphertext. The migration to post-quantum key protection is not a question of if but when, and "when" determines whether the keys your organization uses today are safe for their entire operational lifetime or merely safe until the first cryptographically relevant quantum computer comes online. H33-Key makes the migration transparent, sub-millisecond, and compatible with every secrets management tool you already use. The only decision left is whether to wrap your keys before or after someone else unwraps them.