Homomorphic Encryption and Secure Multiparty Computation
In the CDPSE (ISACA Certified Data Privacy Solutions Engineer) domain of Privacy Architecture, Homomorphic Encryption (HE) and Secure Multiparty Computation (SMPC) are privacy-enhancing technologies (PETs). They let organizations derive value from data without exposing it, which supports privacy by… In the CDPSE (ISACA Certified Data Privacy Solutions Engineer) domain of Privacy Architecture, Homomorphic Encryption (HE) and Secure Multiparty Computation (SMPC) are privacy-enhancing technologies (PETs). They let organizations derive value from data without exposing it, which supports privacy by design, data minimization and confidentiality of data in use, not just at rest or in transit. Homomorphic Encryption allows computations to be performed directly on encrypted data (ciphertext). When the result is decrypted, it matches the result of performing the same operations on the unencrypted data (plaintext). For example, a cloud provider could total encrypted salaries without ever seeing individual values. There are three main variants. Partially Homomorphic Encryption supports one operation, such as addition in Paillier or multiplication in RSA. Somewhat Homomorphic Encryption supports a limited number of operations. Fully Homomorphic Encryption supports arbitrary computations, as in the BFV, CKKS and TFHE schemes. The main trade-offs are heavy computational overhead, larger ciphertexts and complex key management. Secure Multiparty Computation lets several parties, each holding private inputs, jointly compute a function so that only the output is revealed. No party learns the others' inputs. Common techniques include: - secret sharing, which splits data into random shares held by different parties - garbled circuits - oblivious transfer Typical use cases are banks detecting fraud across institutions, hospitals collaborating on research, and private set intersection for advertising measurement. Challenges include communication overhead, coordination among parties, and assumptions about adversaries (semi-honest versus malicious) and collusion. For privacy engineers, both technologies reduce reliance on trusted third parties, limit the impact of breaches, and support compliant third-party and cross-border data sharing under laws such as GDPR. However, they protect inputs rather than outputs, so results may still leak information. Combining them with differential privacy, access controls and threat modeling is therefore recommended. When selecting these controls, engineers should assess performance, maturity and fit for the use case, and document the decision in privacy impact assessments.
Homomorphic Encryption and Secure Multiparty Computation: A CDPSE Privacy Engineering Guide
Introduction
Homomorphic Encryption (HE) and Secure Multiparty Computation (SMPC or MPC) are advanced Privacy-Enhancing Technologies (PETs). They let organizations process, analyze and share insights from sensitive data without exposing the underlying personal information.
For the ISACA Certified Data Privacy Solutions Engineer (CDPSE) exam, these topics belong to the Privacy Architecture and Data Lifecycle domains. You need to know what they protect, when to choose them, their trade-offs, and how they support privacy by design.
Why These Technologies Are Important
Traditional encryption protects data in two of its three states:
• Data at rest: stored on disks or in databases.
• Data in transit: moving across networks, for example via TLS.
The third state, data in use, has historically been the weak point. To compute on encrypted data you normally must decrypt it first. That exposes plaintext to the processing environment, cloud providers, administrators, malware and insiders.
HE and SMPC close this gap. Their importance comes from several drivers:
• Cloud and outsourcing risk: Organizations want to use third-party computing power without trusting the provider with plaintext personal data.
• Regulatory compliance: GDPR, HIPAA, CCPA/CPRA and similar laws require data minimization, purpose limitation and appropriate technical safeguards. GDPR Article 25 (data protection by design and by default) and Article 32 (security of processing) both encourage state-of-the-art safeguards.
• Collaborative analytics: Hospitals, banks and government agencies often need joint insights, such as fraud patterns or disease prevalence, but cannot legally or ethically pool raw data.
• Reduced breach impact: Data that stays encrypted during processing is useless to an attacker who compromises the processing environment.
• Trust and data monetization: Organizations can offer analytics services on customer data without seeing that data, which builds trust.
What Is Homomorphic Encryption?
Homomorphic encryption lets you perform mathematical operations directly on ciphertext. When the result is decrypted, it matches the result you would have obtained by performing the same operations on the plaintext.
In simple terms, if E() is encryption and D() is decryption:
D( E(a) + E(b) ) = a + b
D( E(a) x E(b) ) = a x b
Types of Homomorphic Encryption
• Partially Homomorphic Encryption (PHE): Supports only one type of operation, addition or multiplication, an unlimited number of times.
- RSA (unpadded) is multiplicatively homomorphic.
- Paillier is additively homomorphic.
- ElGamal is multiplicatively homomorphic.
- PHE is efficient and practical for narrow uses such as encrypted vote tallying or summing encrypted values.
• Somewhat Homomorphic Encryption (SHE): Supports both addition and multiplication, but only a limited number of operations. Each operation adds noise, and too much noise makes decryption fail.
• Leveled Homomorphic Encryption: Supports circuits up to a predetermined depth.
• Fully Homomorphic Encryption (FHE): Supports arbitrary computations, unlimited additions and multiplications, on encrypted data.
- Craig Gentry first demonstrated it in 2009 using a technique called bootstrapping, which refreshes ciphertexts to reduce noise.
- Modern schemes include BGV, BFV, CKKS (approximate arithmetic, popular for machine learning) and TFHE.
- Libraries include Microsoft SEAL, OpenFHE (successor to PALISADE), HElib and Concrete.
How Homomorphic Encryption Works in Practice
1. The data owner generates a key pair and encrypts sensitive data with the public key.
2. The encrypted data is sent to an untrusted processor, such as a cloud service.
3. The processor performs the requested computation, such as a sum, average, statistical model or ML inference, directly on the ciphertext. It never sees the plaintext and never holds the private key.
4. The encrypted result is returned to the data owner.
5. The data owner decrypts the result with the private key.
Example: A hospital encrypts patient lab values and sends them to a cloud analytics provider. The provider runs a risk-scoring model on the encrypted values and returns encrypted scores. Only the hospital can decrypt them.
Limitations of Homomorphic Encryption
• Performance overhead: FHE can be thousands to millions of times slower than plaintext computation, depending on the operation.
• Ciphertext expansion: Encrypted data is much larger than plaintext, which raises storage and bandwidth needs.
• Complexity: Implementation needs specialized cryptographic expertise, parameter selection and careful key management.
• Limited operations: Comparisons, branching and non-linear functions are expensive or must be approximated.
• Key management: Whoever holds the private key can decrypt everything, so key protection is critical.
• Output privacy: The decrypted result can still reveal personal information. HE protects inputs during processing, not what the output discloses.
What Is Secure Multiparty Computation?
SMPC is a cryptographic protocol that lets multiple parties jointly compute a function over their private inputs. No party learns anything about the others' inputs beyond what the output itself reveals.
The classic illustration is Yao's Millionaires' Problem (Andrew Yao, 1982). Two millionaires want to know who is richer without revealing their actual wealth to each other.
How SMPC Works
SMPC relies on several core cryptographic building blocks:
• Secret Sharing: The best-known schemes are Shamir's Secret Sharing and additive secret sharing.
- Each party splits its private input into random-looking shares and distributes them to the other parties.
- No single share, and no group of shares below a threshold, reveals anything about the input.
- Parties compute on the shares and then combine the result shares to reveal only the final output.
• Garbled Circuits: Developed by Yao.
- The function is represented as a Boolean circuit.
- One party encrypts (garbles) the circuit, and the other evaluates it using encrypted input labels.
- This is efficient for two-party computation.
• Oblivious Transfer (OT): A sender transfers one of several pieces of information to a receiver. The sender does not learn which piece was chosen, and the receiver learns only the selected piece. OT is a fundamental building block for garbled circuits.
Simple Secret Sharing Example
Three employees want to compute their average salary without revealing individual salaries.
• Alice earns 50, and splits it into random shares 20, 45 and -15, which sum to 50.
• Bob and Carol do the same with their salaries.
• Each person receives one share from every participant and adds the shares they hold.
• The three partial sums are combined to reveal the total, which is then divided by 3.
• Nobody learns anyone else's salary, only the average.
Adversary Models in SMPC
• Semi-honest (honest-but-curious): Parties follow the protocol but try to learn extra information from what they observe. Protocols for this model are cheaper.
• Malicious: Parties may deviate arbitrarily from the protocol. Protocols for this model are stronger but more expensive.
• Honest majority vs. dishonest majority: These define how many colluding parties the protocol can tolerate.
Limitations of SMPC
• Communication overhead: Parties must exchange many messages, so network latency and bandwidth become bottlenecks.
• Coordination: All parties must be online and participate, often in multiple rounds.
• Collusion risk: If enough parties collude above the threshold, inputs can be reconstructed.
• Output leakage: The result itself may reveal information, especially with small groups or repeated queries.
• Complexity: Implementation and governance agreements among parties are needed.
Comparing HE and SMPC
• Number of parties: HE typically involves one data owner outsourcing computation to an untrusted party. SMPC involves multiple parties, each with its own private data, computing jointly.
• Trust model: HE requires no trust in the processor. SMPC requires that no more than a threshold of parties collude.
• Main bottleneck: HE is limited by computation. SMPC is limited by communication and network rounds.
• Key management: HE has a central private key. SMPC often has no single key, because trust is distributed.
• Typical use: HE suits secure cloud outsourcing and encrypted queries or inference. SMPC suits joint analytics, private set intersection, auctions, threshold signatures and collaborative fraud detection.
• Combination: The two can be combined. Hybrid protocols use HE inside SMPC.
Related Privacy-Enhancing Technologies to Distinguish
• Differential Privacy: Adds calibrated statistical noise to outputs to protect individuals in aggregate results. It protects the output, whereas HE and SMPC protect inputs during computation. They are often combined.
• Trusted Execution Environments (TEEs): Hardware-based enclaves, such as Intel SGX, AMD SEV and ARM TrustZone, that protect data in use. Their trust rests on the hardware vendor, not on cryptography alone.
• Federated Learning: Trains ML models across decentralized devices without centralizing raw data. It is often combined with SMPC (secure aggregation) or differential privacy.
• Zero-Knowledge Proofs: Prove a statement is true without revealing the underlying data, for example proving you are over 18 without revealing your birthdate.
• Pseudonymization, Tokenization and Anonymization: Transform data before processing. They do not provide computation on encrypted data.
• Private Set Intersection (PSI): A specific SMPC application in which two parties find common records without revealing non-matching records.
Real-World Use Cases
• Healthcare: Genomic research across institutions, and encrypted medical predictions.
• Finance: Banks jointly detecting money laundering or fraud without sharing customer lists, and credit scoring on encrypted data.
• Advertising: Measuring ad conversions by matching advertiser and publisher data through PSI.
• Government: The Boston Women's Workforce Council used SMPC to measure the gender pay gap without companies revealing individual salaries. Estonia has used SMPC for tax and education research.
• Elections: Encrypted vote tallying using additive HE.
• Cryptocurrency and key custody: Threshold signatures and MPC wallets ensure no single party holds the full private key.
• Password breach checking: Checking whether credentials appear in breached sets without revealing them.
Privacy Engineering Considerations for the CDPSE
A privacy engineer should evaluate HE and SMPC as part of a risk-based architecture:
• Conduct a DPIA/PIA: Determine whether processing sensitive data in use creates high risk that justifies an advanced PET.
• Assess the threat model: Who is untrusted, the cloud provider, partners or insiders? This decides between HE (one untrusted processor) and SMPC (mutually distrustful peers).
• Balance utility and performance: Confirm that latency and cost are acceptable for the business use case.
• Plan key management: Cover generation, storage (HSMs), rotation and access control.
• Consider output privacy: Pair the technique with differential privacy, minimum aggregation thresholds or query limits.
• Establish governance: Draft data-sharing agreements, define roles (controller vs. processor) and assign accountability among SMPC parties.
• Use vetted libraries and standards: Never build custom cryptography. Follow emerging standards such as HomomorphicEncryption.org guidance, ISO/IEC work on HE, and NIST's privacy-enhancing cryptography efforts.
• Plan for crypto-agility and post-quantum readiness: Many FHE schemes are lattice-based and considered quantum-resistant. Paillier and RSA-based PHE are not.
• Understand legal status: Encrypted data generally remains personal data under GDPR for anyone who can decrypt it. PETs reduce risk but do not automatically remove regulatory obligations.
Exam Tips: Answering Questions on Homomorphic Encryption and Secure Multiparty Computation
1. Learn the keyword triggers.
• Phrases like compute on encrypted data, process data without decrypting it, untrusted cloud processing or outsourced analytics without exposing plaintext point to Homomorphic Encryption.
• Phrases like multiple organizations, jointly compute, without revealing their individual inputs, no trusted third party or collaborative analysis between competitors point to Secure Multiparty Computation.
• Phrases like protect individuals in published statistics or add noise to query results point to Differential Privacy, not HE or SMPC.
• Phrases like hardware enclave or secure processor region point to a Trusted Execution Environment.
2. Remember the data state. Both HE and SMPC protect data in use. When a question asks how to protect data during processing, avoid answers focused only on data at rest (disk encryption) or data in transit (TLS).
3. Know the main drawback. When asked for the biggest challenge or limitation, the answer is usually performance and computational overhead for HE, and communication overhead and coordination for SMPC. Complexity and key management are secondary answers.
4. Distinguish PHE, SHE and FHE.
• If the question involves only addition, such as tallying votes or summing values, partially homomorphic encryption (like Paillier) is the most efficient fit.
• If it requires arbitrary computation, FHE is needed.
5. Choose the BEST answer in context. ISACA questions often have several technically correct options.
• Pick the one that best fits the business need, the threat model and the principle of least exposure.
• If the business cannot tolerate latency, a heavy FHE solution may not be the best answer. A TEE, tokenization or aggregation might be more appropriate.
6. Think risk first. The CDPSE emphasizes risk-based decisions. Expect answers like perform a privacy impact assessment or define requirements to come before implement HE when a question asks what to do FIRST.
7. Do not over-claim. Be wary of options that say HE or SMPC makes data anonymous or removes all compliance obligations. The output can still leak information, and the key holder can still decrypt. Look for answers acknowledging that PETs reduce risk but must be complemented by governance.
8. Know the collusion concept. SMPC security assumes that fewer than a threshold number of parties collude. If a question asks what could undermine SMPC, collusion among participants is a prime answer.
9. Recognize combinations. Federated learning plus secure aggregation (SMPC) plus differential privacy is a common layered architecture. Questions may reward the answer that combines PETs for defense in depth.
10. Tie it to privacy principles. HE and SMPC support:
• data minimization, since parties see only what is needed
• purpose limitation
• privacy by design
• confidentiality
• reducing third-party and vendor risk
When an answer choice links the technology to these principles, it is often the correct one.
11. Avoid custom cryptography. If a question offers developing an in-house encryption algorithm versus using an established, peer-reviewed library, always choose the established library.
12. Watch the role of keys. In HE, the processing party should never hold the decryption key. An answer that gives the cloud provider the private key defeats the purpose.
Sample Practice Questions
Q1. A healthcare organization wants a cloud provider to run predictive analytics on patient records. The provider must never have access to readable patient data. Which technology BEST meets this requirement?
A. Transport Layer Security
B. Fully homomorphic encryption
C. Data masking
D. Full disk encryption
Answer: B. FHE allows computation on encrypted data, so the provider never sees plaintext. TLS and disk encryption protect data in transit and at rest only. Masking reduces the analytic utility of the data.
Q2. Three competing banks want to identify customers who appear on all their fraud watchlists without sharing their full lists. Which approach is MOST appropriate?
A. Send all lists to a trusted consultant
B. Secure multiparty computation (private set intersection)
C. Differential privacy
D. Pseudonymize and exchange lists
Answer: B. SMPC/PSI lets the banks find common entries without revealing non-matching records or relying on a trusted third party. Exchanging pseudonymized lists still risks re-identification through matching.
Q3. What is the PRIMARY barrier to widespread adoption of fully homomorphic encryption?
A. Lack of regulatory acceptance
B. Significant computational overhead
C. Inability to encrypt numerical data
D. Vulnerability to man-in-the-middle attacks
Answer: B. Performance overhead is FHE's main limitation.
Q4. Which condition would MOST likely compromise the confidentiality guarantees of a secret-sharing-based SMPC protocol?
A. Using TLS between parties
B. Collusion among a threshold number of participants
C. Encrypting the final output
D. Running the protocol in the cloud
Answer: B. Collusion above the threshold allows the secret shares to be reconstructed.
Q5. An organization needs to publish aggregate statistics computed with SMPC, but worries that the results could reveal information about individuals in small groups. What should the privacy engineer recommend?
A. Switch to homomorphic encryption
B. Apply differential privacy or minimum aggregation thresholds to the output
C. Increase the encryption key length
D. Remove TLS to improve performance
Answer: B. HE and SMPC protect inputs, not outputs. Output privacy requires techniques like differential privacy or thresholds.
Key Takeaways
• HE lets a single data owner outsource computation on encrypted data to an untrusted party.
• SMPC lets multiple distrustful parties jointly compute a result without revealing their individual inputs.
• Both protect data in use, the gap left by traditional encryption.
• Their main trade-offs are performance (HE) and communication and coordination (SMPC).
• Neither protects what the output reveals. Combine them with differential privacy and governance controls.
• On the exam, map scenario keywords to the right PET, think risk-first, and choose the answer that best balances privacy, utility and business needs.
Unlock Premium Access
Certified Data Privacy Solutions Engineer
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 3000 Superior-grade Certified Data Privacy Solutions Engineer practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- CDPSE: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!