up:: Migration Architecture MOC

The Two-Layer Questions

The two-layer questions are two questions you put to the storage team about any stored data set: what algorithm encrypts the data itself, and what algorithm wraps the key that protects it. They exist because a data-at-rest system encrypts on two layers, and the panic about post-quantum migration almost always aims at the wrong one. The data layer is usually AES-256, which survives a quantum computer, so it stays put. The exposure lives one layer up, in the key-wrapping layer, which very often uses RSA, a public-key algorithm Shor’s algorithm breaks.

The default disposition the two answers produce is re-wrap, don’t re-encrypt: rotate the wrapping onto post-quantum protection and re-wrap the same AES keys, without ever touching the data. Two specific answers flip a data set into the re-encrypt column instead, and finding those is the whole point of asking.

The short version:

1. Ask two questions per stored data set: which algorithm encrypts the data, and which algorithm wraps its key.
2. Most archives are AES-256 wrapped by RSA. The AES survives a quantum computer, and only the wrapping is exposed, so the fix is key rotation, not re-encryption.
3. Re-wrapping rotates the key-protection layer to post-quantum and re-issues protection for the same AES keys. The data is never decrypted or rewritten, which is why it costs a fraction of a re-encryption program.
4. Two answers force full re-encryption: data encrypted directly with a quantum-vulnerable algorithm, and long-lived data still under AES-128, which has a thinner margin under Grover’s algorithm and gets rebuilt to AES-256.
5. The output is one split: a large, cheap key-rotation project and a small, named set that genuinely needs the data itself re-encrypted.

Picture a warehouse of strongboxes. Each box is sealed with a heavy padlock a quantum computer can’t pick, and that padlock is the AES encryption on the data. The keys to every padlock are kept together in one master safe, and the master safe’s combination lock is the old, breakable kind, which is the RSA wrapping on the keys. An attacker who cracks the combination gets every padlock key and opens every box, without ever defeating a single padlock.

The first question asks what kind of padlock is on the boxes. The second asks what kind of lock is on the master safe. Answer both and you know whether the job is swapping one combination lock, which is cheap, or re-sealing thousands of boxes, which is not.

What are the two-layer questions?

The two-layer questions are a triage tool with a fixed wording, a fixed respondent, and a fixed output. For every stored data set in the estate, the storage or data-platform team answers, in these words:

1. What algorithm encrypts the data itself?
2. What algorithm wraps the key that protects it?

The two answers place the data set into one of two dispositions:

1. Re-wrap. The data is symmetric (AES-256) and only the wrapping is quantum-vulnerable. This is most of the archive, and it becomes a key-rotation line item.
2. Re-encrypt. The data’s own protection is quantum-vulnerable or too thin, so the bytes have to be decrypted and rewritten under a quantum-safe scheme. This is the small, expensive exception.

The framework applies to any data set that lives at rest: object storage, database files, backups, log archives, document stores. It applies whether the answers come from a person, a key-management console, or a machine-readable CBOM row. Where it does NOT apply is data whose encryption you neither hold nor can see into, covered in its own section below. And it deliberately measures only how the data was protected. It does not decide sequence. That comes from how long each set must stay secret, which is The Shelf-Life Question, gestured at here and taught in full there.

The two questions are a targeted application of two of The Four Questions of a cryptographic inventory, which algorithm and where it runs, aimed at the one place a data-at-rest audit reliably misreads: the layer above the data.

Why does a stored data set have two cryptographic layers?

Because almost every real storage system uses envelope encryption, a design that splits protection into a workhorse layer and a guard layer so a small, tightly-held key can protect an enormous volume of data. Understanding the split is what lets you fix the correct layer instead of the expensive one.

1. The data-encryption key (DEK) protects the data. A symmetric key, in a modern system almost always AES-256, encrypts the actual bytes: the tables, the objects, the backup blocks. It does the bulk work, and it is what the first question asks about.
2. The key-encryption key (KEK) protects the DEK. The DEK is itself encrypted, wrapped by a second key held in a key-management service or a hardware security module. That wrapping operation very often uses a public-key algorithm such as RSA, and it is what the second question asks about.
3. The wrapped DEK is stored next to the data. The encrypted data key travels and rests alongside the ciphertext it protects, so it lives in the same databases and backups an adversary can copy. A key-management hierarchy stacks these: a root key protects key-encryption keys, which wrap data keys, which encrypt the data.

The consequence is the thing the two questions surface. A quantum attacker’s path to your stored data runs through the public-key operation that wrapped the AES key, never through the AES that encrypted the data. Read only the first layer and you see AES and conclude you’re safe, while the key beside it sits under RSA. The second question is the one that opens the layer the audit skipped.

Source: AWS, “AWS Key Management Service concepts, envelope encryption and data keys,” docs.aws.amazon.com; the key-hierarchy layering follows NIST SP 800-57 Part 1 Rev. 5, §5 to §6, May 2020, SP 800-57.

Why re-wrap instead of re-encrypt?

Because for the overwhelming majority of stored data, the data’s own encryption is already quantum-safe, so the scope of the migration is fixing how the keys are protected. AES-256 under Grover’s algorithm retains roughly 128 bits of effective strength, and that figure is the algorithm’s post-Grover effective security, never its key size. Grover provides a square-root speedup against a symmetric key, which halves the effective bit strength rather than breaking the cipher, and 128 bits of effective strength sits far beyond anything a machine will reach for the foreseeable future. NIST’s position is that a sufficiently long symmetric key remains secure against a quantum attacker, which is why symmetric encryption sits in the monitor-and-strengthen lane rather than the replace lane.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NISTIR 8105. AES-256 is standardized in FIPS 197, FIPS 197, and its 256-bit classical security strength is tabulated in NIST SP 800-57 Part 1 Rev. 5, SP 800-57.

So the disposition writes itself. Where the data is AES and only the wrapping is vulnerable, you move the key-wrapping and key-delivery layer to a post-quantum algorithm and re-wrap the existing data keys under it, issuing fresh protection for the same underlying AES keys. The data stays exactly where it is, encrypted exactly as it was, and never gets decrypted or rewritten. That is a key-management operation: fast, cheap, and the thing a key-management system was built to do cleanly. It is a categorically different job from decrypting and re-encrypting petabytes, and the entire cost saving in a data-at-rest migration comes from knowing you almost always need the first one. The table below lays out the layers and their dispositions.

Layer	What it does	Typical algorithm	Quantum-vulnerable?	Disposition
Data-encryption layer	Encrypts the data bytes	AES-256	No, Grover only halves the effective strength	Leave in place
Data-encryption layer, weak	Encrypts the data bytes	AES-128	Thin margin under Grover	Re-encrypt to AES-256 if the data is long-lived
Data-encryption layer, direct public-key	Encrypts the data bytes directly	RSA / ECC	Yes, Shor breaks it	Re-encrypt under a quantum-safe scheme
Key-wrapping layer	Wraps the data key	RSA, very often	Yes, Shor breaks it	Re-wrap under post-quantum protection (rotation)
Key-wrapping layer, symmetric	Wraps the data key	AES key-wrap	No	Leave in place, verify the delivery path

Note the qualifier on the wrapping row: the wrapping very often uses RSA, and it is not a universal rule. Some key hierarchies wrap the DEK with a symmetric KEK and carry no public-key operation in the wrapping path at all, which is why the second question is a question and not an assumption.

When do you actually have to re-encrypt?

Full re-encryption is warranted in exactly two cases, and the two questions are built to find both. Everything outside them is a re-wrap.

1. The data was encrypted directly with a quantum-vulnerable algorithm. If the first question comes back as RSA, elliptic-curve, or any scheme whose confidentiality rests on public-key math rather than a symmetric cipher, the data itself is exposed, and no amount of re-wrapping helps because there is no surviving symmetric layer underneath. This is uncommon for bulk storage, but it shows up in encrypted-email archives, some document-protection formats, and older application-level encryption that reached for a public key directly. The data has to be decrypted and re-encrypted under a quantum-safe scheme.
2. Long-lived data is still under AES-128. AES-128 survives Grover with a thinner margin than AES-256, so it retains roughly 64 bits of effective strength under a square-root speedup. That is still a hard target, and for most data it is fine. For data that must stay confidential for decades, the sensible move is to rebuild it up to AES-256 so the margin is generous rather than adequate. This is a re-encryption of the data bytes, gated by how long the data has to outlive the transition.

Both exceptions are worth the effort to isolate precisely, because they are the parts of the estate where a blanket re-wrap would quietly leave a real hole. The discipline is that this stays a per-data-set decision driven by discovery, never a mood. A blanket re-encrypt-everything program spends heavily on the AES data that was never at risk, and a blanket re-wrap-everything program walks straight past these two cases. The two questions are what separate them.

What does the two-layer triage look like on a real archive?

Run the two questions across a sample of stored data sets every mid-size organization recognizes. The figures are illustrative; the shapes are universal. Each row records the answer to question one, the answer to question two, whether anything in the stack is quantum-vulnerable, and the disposition that follows.

Stored data set	What encrypts the data?	What wraps the key?	Vulnerable layer	Disposition
Customer-records warehouse	AES-256 transparent encryption	RSA-2048 KEK in the cloud KMS	The wrapping	Re-wrap: rotate the KEK to post-quantum
Nightly financial backups	AES-256	RSA-3072 KEK in an HSM	The wrapping	Re-wrap: rotate the KEK, gated by HSM firmware
Log archive	AES-256	AES key-wrap (symmetric KEK)	None	Leave in place, confirm the access path isn’t public-key
Legacy document store from 2012	AES-128, long retention	RSA-2048	Both: thin data margin and vulnerable wrapping	Re-encrypt up to AES-256 and re-wrap under post-quantum
Encrypted email archive	RSA directly on message bodies	Same RSA key pair	The data itself	Re-encrypt under a quantum-safe scheme

Now read what the two columns did. The first three rows are the common case: symmetric data, so the AES stays untouched, and the only question is whether the wrapping is public-key (rows one and two, a rotation) or already symmetric (row three, nothing to do on the wrapping). Those rows are the large, cheap key-rotation project. The last two rows are the exceptions the questions exist to catch: an AES-128 set old enough and long-lived enough to rebuild, and an email archive whose bytes were encrypted with a public key directly. Those two rows are the small, named re-encryption list.

That split is the entire output. One archive that felt like a monolithic re-encrypt-everything nightmare resolves into a large rotation job the key-management system already knows how to run, plus a short list of specific data sets, each with a reason attached, that genuinely need the expensive treatment. The expensive part is small and named instead of vast and vague.

Where does this fit in the migration?

The two-layer questions produce the what of the data-at-rest job. They do not set the when. Sequence comes from how long each data set must stay secret, which is The Shelf-Life Question: the sets carrying the longest-lived secrets move first, because every day a long-lived wrapped key sits under RSA is another day an adversary can copy it and wait. The two frameworks compose cleanly. Shelf-life ranks the queue, and the two-layer questions decide, for each set in the queue, whether the move is a re-wrap or a re-encrypt.

Upstream, the answers land in the CBOM as rows, because the two questions are a focused pass of the broader inventory in The Four Questions. Downstream, the re-wrap work joins the key-management track (gated by whether the HSM or KMS holding the wrapping key supports post-quantum algorithms yet), while the rare re-encrypt work becomes its own scoped project. The database-specific version of all this, plus the client-connection surface a database also carries, lives in PQC for Databases and Data-at-Rest Key Wrapping, and the general storage treatment is Re-Encrypting Data at Rest for PQC. Building crypto-agility into the storage layer is what keeps the next transition from being another bespoke program, because a system designed to rotate its wrapping keys and swap algorithms cleanly does this as scheduled maintenance rather than a crisis.

Where do the two-layer questions break?

Published limits are part of the tool. This one has three honest edges.

1. Data encrypted client-side by a format you don’t control. When a third-party application or a SaaS product encrypts data before it ever reaches your storage, you hold the ciphertext while both layers stay on the provider’s side. The first question has no answer you can give, because the data key lives with the provider, and the second is theirs to act on, because the wrapping happens inside their software. The data set converts from a triage row into a vendor-dependency line: ask the provider what protects it, date-stamp the answer or the non-answer, and track it as a surface you can see but cannot change.
2. Fully symmetric estates. Where a storage system wraps its data keys with a symmetric KEK and delivers them over a channel that carries no public-key operation, both questions come back symmetric and the disposition is to leave it in place. That is a real and correct result, and the framework’s job there is confirmation rather than remediation. The one thing to verify is the delivery and access path, because a symmetric wrapping is often still reached through a TLS handshake whose key exchange is classical, and that channel migrates on the protocol track.
3. The irreversibility limit. Re-wrapping and re-encryption both protect the forward path only. Rotating the wrapping onto post-quantum protection secures every future access to that data set, and it does nothing for a wrapped key an adversary already copied. That captured copy stays crackable by a future quantum computer no matter what you do to your own systems now, which is why the sequencing rule matters so much: the longest-lived secrets move first, before more of their wrapped keys are harvested. The framework triages what you still hold. It cannot reach a copy that already left.

Pro tips

1. Put the second question to the people who run the keys, not the people who run the app. Application teams reliably answer question one, because the data cipher is theirs. The wrapping lives in the key-management service or the HSM, so the answer to question two comes from whoever administers that, and it is exactly the answer the app team tends to assume rather than know.
2. When question one comes back as “we use encryption,” keep asking until it has a parameter in it. A family name is four blanks pronounced as one word. The disposition depends on AES-256 versus AES-128 versus a direct public key, and none of those distinctions survives an answer that stops at “encrypted.” This is the first inventory question applied at the point it matters most.
3. Treat the HSM or KMS firmware as the real constraint on the re-wrap work. Re-wrapping under a post-quantum KEK depends on the device or service that holds the wrapping key supporting post-quantum algorithms. A keystore that can’t yet accept post-quantum wrapping is a vendor-dependency line with a date on it, not a task you can schedule freely.
4. Confirm the delivery path even when both layers come back symmetric. A symmetric-wrapped data set with a classical TLS channel carrying its keys or its query results still has a harvestable surface. The two questions clear the at-rest layers; the channel is a separate, and usually more urgent, job.
5. Record the wrapped-key exposure as a harvest clock, not a someday problem. The wrapped DEK sits in the same backups an adversary can copy today, so a long-lived data set under an RSA wrap is exposed to harvest-now-decrypt-later right now. That is what justifies moving it ahead of a short-lived set with the same wrapping.
6. Split a mixed data set rather than averaging it. A backup that mingles a handful of decades-long records with a warehouse of short-lived ones inherits the disposition of its longest-lived, most-vulnerable member. If that drags a huge cheap set into the expensive lane, split the long-lived records out and treat them separately.

How do you use the two-layer questions in the boardroom?

One level up, the two questions convert a terrifying line item into a scoped decision a board can act on. What lands on a CISO’s desk is usually some version of “we have 15 years of archives, do we seriously have to go back and re-encrypt all of it?” The and reassuring answer is no, and the two questions are how you show the work.

The board-facing artifact is the split itself: a large key-rotation project, sized in key-management effort rather than data volume, and a short list of specific data sets that need full re-encryption, each with the reason it made the list. Three properties make that slide survive scrutiny:

1. The scope is defensible per data set. Every row traces to two concrete answers about how that data was protected, so the follow-up “why is this one expensive and that one cheap?” is answered by the data set’s own two layers, not by a blanket assumption in either direction.
2. The cost shape is the headline. A re-encrypt-everything program prices against petabytes; the two-question split prices the vast majority as key-management work and reserves the volume-scaled cost for a small, named set. That is the difference between a budget line a board approves and one it flinches at.
3. The honesty about harvested copies is on the record. Stating that rotation protects the forward path and cannot reach an already-harvested copy is what makes the sequencing defensible, and it is the kind of candor a board and a regulator both read as competence.

Common misconceptions

1. “Quantum means I have to re-encrypt all my archives.” Most archives are AES-256 wrapped by a public key. The AES survives, so the fix is rotating the wrapping, which is key rotation, not re-encryption. The sweeping fear aims at the layer that was never the problem.
2. “It’s all just key rotation, so we can move on.” Two specific answers force a real re-encryption: data encrypted directly with a quantum-vulnerable algorithm, and long-lived data still under AES-128. A blanket rotation leaves both exposed, and the two questions exist to find them.
3. “We rotated the keys, so the stored data is safe now, full stop.” Rotation protects everything going forward and reaches nothing an adversary already copied. A wrapped key harvested while it sat under RSA stays crackable by a future machine, which is why the longest-lived secrets move first.
4. “We use AES, so we’re fine.” That answers only the first question. The key beside the data is very often wrapped in RSA, and that wrapping is the quantum-vulnerable layer a data-only audit never opens.
5. “The data key is the part quantum breaks.” The data-encryption key is symmetric and survives with a large key. The key-encryption key, the public-key operation that wraps the DEK, is the part Shor’s algorithm threatens.
6. “Re-wrapping means decrypting and re-encrypting the data.” Re-wrapping touches only the key. The data stays encrypted exactly as it was and is never read or rewritten, which is the entire reason it is cheap.
7. “AES-128 is broken by quantum.” AES-128 survives Grover with a thinner margin, keeping roughly 64 bits of effective strength. It is not broken, and the recommendation for long-lived data is to rebuild up to AES-256 for a comfortable margin, never a claim that AES fell.

Questions people ask

What exactly are the two questions? For each stored data set: what algorithm encrypts the data itself, and what algorithm wraps the key that protects it. The first answer is usually AES-256 and safe; the second is usually RSA and the real exposure. Keep both intact, because the disposition depends on the pair, not either one alone.

Who do I ask? Question one goes to the storage or application team that owns the data cipher. Question two goes to whoever administers the key-management service or the HSM that holds the wrapping key, because that answer is the one the data team tends to assume rather than know.

Does AES-256 really survive a quantum computer? Yes, with a sufficient key length. Grover’s algorithm gives a square-root speedup, which takes AES-256 to roughly 128 bits of effective strength, and that is effective strength rather than key size. It sits far beyond any foreseeable machine, which is why the data layer stays put while the wrapping migrates.

What if the wrapping comes back symmetric instead of RSA? Then there is no public-key operation in the wrapping path and the at-rest layers need no change. Confirm the delivery and access path separately, because the keys may still travel over a classical TLS channel that migrates on its own track.

How do I find data that was encrypted directly with a vulnerable algorithm? Through discovery, and by asking the first question honestly. Encrypted-email stores, some document-protection formats, and older application-level encryption are the usual places a public key touched the data directly rather than a symmetric key. Those are the sets whose first answer is RSA or elliptic-curve, and they go on the re-encrypt list.

Do I move all the re-wrap sets at once? No, sequence them. Rank by how long each data set must stay secret using The Shelf-Life Question, and move the longest-lived first, because a long-lived wrapped key under RSA is exposed to harvesting every day it waits.

If I re-wrap, am I safe from harvest-now-decrypt-later? For copies you control, going forward, yes. Re-wrapping protects your stored copy from that day on, and it cannot reach a copy an adversary already harvested, which stays exposed to a future machine. Closing the window early on the longest-lived sets is what limits how much gets harvested before you move.

Is this anything more than key rotation? For most of the estate it is exactly key rotation, and that is the good news. The extra steps are the two exceptions, the direct-public-key data and the long-lived AES-128 data, which rotation alone would leave exposed. The questions are what tell you which data sets are ordinary rotation and which two are not.

How is this different from the four questions? The Four Questions map a whole cryptographic inventory: which algorithm, where it runs, what it protects, who controls it. The two-layer questions are a focused application of the first of those, aimed at data at rest, where the algorithm that matters most is the one wrapping the key rather than the one encrypting the data.

---

Everything here is the map, given freely. When your team needs its whole storage estate triaged by these two questions, the large key-rotation project separated from the small set that genuinely needs re-encryption, and the whole thing sequenced by how long each data set has to stay secret, that’s the work I do. Request the workshop.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.