Homomorphic encryption, forward secrecy and data in use

Why this matters

Data exists in three states — at rest, in transit, and in use — and the third is the one almost every design ignores. Encryption at rest and in transit are solved problems with defaults; data being processed has historically been plaintext in memory, readable by the operating system, the hypervisor, the platform operator and anyone who compromises any of them.

This lesson covers the two answers to that, which are very different in maturity, and one property of transport encryption that belongs here because it addresses the same underlying worry as post-quantum: what a future compromise reveals about today's traffic.

The exam angle is about applicability rather than mechanism. CAS-005 will describe a requirement — a third party must compute on data it may not see, a compromise of a server's long-term key must not expose past sessions, a workload must run where the operator is not trusted — and ask which technique applies. Knowing what each can and cannot do, and what it costs, is the examinable content.

The lesson

Computing on encrypted data: what is practical today and what is not

Homomorphic encryption allows computation on ciphertext, producing a ciphertext whose decryption equals the result of the same computation on the plaintext. The party performing the computation never sees the data.

The property is genuinely remarkable and its practical scope is narrow, which is the balance to hold.

Partially homomorphic schemes support one operation — addition or multiplication — on ciphertext, unlimited times. Several well-known public-key schemes have this property, some by accident of their construction. They are efficient and usable today, and the class of computations they support is correspondingly limited.

Somewhat homomorphic schemes support both operations but only to a bounded depth, because each operation adds noise to the ciphertext and accumulated noise eventually makes decryption fail.

Fully homomorphic schemes support arbitrary computation, achieved by periodically reducing the accumulated noise. This is the general-purpose version and it is the one carrying the large performance cost — orders of magnitude slower than computing on plaintext, with large ciphertexts.

Where it is genuinely used today: private information retrieval, where a client queries a database without revealing the query; encrypted aggregation and statistics across parties; specific privacy-preserving machine-learning inference; and secure outsourced computation of simple functions. Those share a shape — a narrow, well-defined computation over data of high sensitivity, where the privacy is worth a large cost.

Where it is not the answer, and a scenario offering it is usually offering a distractor: general application processing, anything latency-sensitive, and any case where a simpler control — not sending the data at all, tokenising it, or computing inside a trusted environment — achieves the requirement.

Two related techniques are worth recognising because they solve adjacent problems more cheaply. Secure multi-party computation lets several parties jointly compute a function over their combined inputs without revealing them to each other. Zero-knowledge proofs let one party prove a statement is true without revealing why — proving an attribute without disclosing the underlying data.

Partially and fully homomorphic schemes, and the performance cost that decides use

The decision in practice is almost always made by cost, so it is worth being concrete about what that cost looks like and when it is acceptable.

The overhead has three components: ciphertext expansion, so encrypted data is substantially larger than plaintext, affecting storage and bandwidth; computation, which is dramatically slower per operation; and key and parameter management, which is more complex than conventional encryption because parameters must be chosen for the computation depth intended.

That cost profile makes a clean decision rule. Homomorphic encryption is viable where:

• The computation is small and well defined, not a general workload.
• The data is high value enough to justify the overhead.
• Latency is tolerant — batch or asynchronous rather than interactive.
• There is no simpler control that meets the requirement.

That last condition eliminates most candidate uses, and eliminating them is the right answer rather than a failure of ambition. If the third party does not actually need the raw values, tokenisation or aggregation solves it far more cheaply. If the computation can be performed inside your boundary, the problem disappears. If the concern is the platform operator specifically, confidential computing — the next section — is dramatically cheaper.

The exam-facing summary: homomorphic encryption is the right answer when the computing party must be cryptographically unable to see the data and the computation is narrow. In every other case, look for the cheaper control first, and a scenario where a simpler option is available is usually testing exactly that judgement.

Secure enclaves and confidential computing as the other answer to data in use

The practical answer to data in use today, and the one that appears in real architectures.

A secure enclave is a hardware-protected region of memory whose contents are encrypted and inaccessible to everything outside it — including the operating system, the hypervisor and the platform operator. Code and data inside are protected by the processor itself.

Confidential computing is the application of this to workloads: running an entire virtual machine or container inside a hardware-protected environment so that the infrastructure provider cannot read its memory.

Its decisive advantage over homomorphic encryption is performance. Computation inside an enclave runs at close to normal speed, because it is ordinary computation on plaintext — the plaintext simply exists in a region nothing else can read. That makes it applicable to general workloads rather than to narrow functions.

Attestation is what makes it trustworthy, and it is lesson twenty-two's mechanism applied here: the enclave produces a signed statement of what code is running inside it, rooted in the processor's hardware key. A remote party can verify that statement before releasing secrets to the enclave — which is the step that matters. Without attestation you are trusting that the enclave contains what you think it does; with it, you have evidence.

The limits, and scenarios probe them:

• You are trusting the hardware vendor and their implementation. Enclave technologies have had side-channel and architectural vulnerabilities.
• Side channels remain a live concern — timing, cache and speculative execution attacks can leak information from inside an enclave without breaking its memory protection.
• Available memory and programming model constraints vary by technology, and some require the workload to be structured for it.
• Portability between vendors is limited, which is a supplier dependency.

The comparison worth carrying into an exam: homomorphic encryption gives a cryptographic guarantee at enormous cost for narrow computations; confidential computing gives a hardware guarantee at modest cost for general computation. If the requirement is "the cloud provider must not be able to read this while it is being processed", confidential computing is nearly always the answer.

Perfect forward secrecy: what a compromised long-term key does and does not reveal

Forward secrecy is the property that compromising a long-term private key does not allow decryption of previously recorded sessions.

The mechanism: instead of using the server's long-term key to transport a session key, both parties perform an ephemeral key exchange, deriving a session key from values that exist only for that session and are discarded afterwards. The long-term key authenticates the exchange rather than protecting it. An attacker who later obtains the long-term key can impersonate the server going forward — which is serious — but cannot decrypt any recorded past session, because the material needed to derive those session keys no longer exists anywhere.

Why it belongs beside post-quantum in the same objective: both address the same adversary, who records now and attacks later. Forward secrecy defeats the version of that adversary who obtains the long-term key; post-quantum migration defeats the version who acquires a quantum capability. An estate concerned about recorded traffic needs both, and neither substitutes for the other.

Practical points that appear in scenarios:

• Current protocol versions require it, which is one of the substantive reasons to insist on them rather than a version-number preference.
• It is incompatible with passive decryption for inspection. An organisation that decrypts traffic by giving a monitoring device the server's private key cannot do so with forward secrecy — inspection must move to an endpoint or to a terminating proxy, which is the architectural point lesson twenty-four made about SASE.
• Session resumption can undermine it if resumption tickets are protected by a long-lived key that is never rotated. The ticket key is then effectively a long-term key with the property forward secrecy was meant to remove, and rotating it frequently is what preserves the guarantee.
• It protects the transport, not the endpoints. Data stored at either end is unaffected, and a scenario proposing forward secrecy as a response to a data-at-rest exposure is proposing the wrong control.

Choosing between these by the adversary you are actually defending against

The closing synthesis for the objective, expressed as the question each technique answers.

Three closing observations that generalise.

Name the adversary before choosing the control. Every row above is a different threat, and a technique chosen without naming which one is being addressed will be both expensive and misaimed. This is lesson nine's point about actor characteristics, arriving in cryptographic form.

Cost varies by orders of magnitude across that table, so proportionality is not optional. A design applying the most powerful technique regardless of the requirement is the answer CAS-005 offers and rejects, for the same reason lesson seventeen gave about key models.

These are not alternatives to the basics. Forward secrecy does not remove the need for certificate validation; confidential computing does not remove the need for access control; homomorphic encryption does not remove the need for data minimisation — and the cheapest control in the whole table remains not sending the data at all.