An Honest-but-Curious (HbC) adversary, also known as a semi-honest adversary, is a participant in a cryptographic protocol who follows the protocol's instructions correctly but may later attempt to learn additional, unauthorized information from the internal state and message transcripts they observe during execution. This model assumes the adversary does not deviate from the prescribed algorithm but is passively curious, analyzing all received data to infer private inputs from other parties. It is the standard security model for many privacy-preserving machine learning techniques, including foundational secure aggregation protocols in federated learning.
Glossary
Honest-but-Curious Adversary

What is an Honest-but-Curious Adversary?
A foundational security model in privacy-preserving computation that defines a specific type of threat actor.
The HbC model provides a realistic baseline for analyzing systems where participants have an incentive to be compliant but cannot be fully trusted with raw data, such as in cross-silo federated learning among competing institutions. Defenses against HbC adversaries, like secure multi-party computation (MPC) with additive secret sharing or homomorphic encryption, ensure that even with perfect protocol adherence, no individual's private contribution is revealed. This model is weaker than the malicious adversary model but is crucial for designing practical, efficient systems for secure aggregation protocols where active sabotage is a secondary concern to data leakage.
Core Characteristics of the Honest-but-Curious Model
The Honest-but-Curious (HbC) adversary, also known as a semi-honest adversary, is a foundational security model in cryptography and privacy-preserving computation. It defines a participant who follows the protocol's instructions correctly but may later analyze all observed messages to extract additional, unauthorized information.
Protocol Compliance
An Honest-but-Curious adversary is bound by the rule that they must follow the prescribed protocol exactly. They cannot:
- Send incorrect or malformed messages.
- Refuse to send required messages.
- Collude with other parties in ways not defined by the protocol.
This distinguishes them from a Malicious Adversary, who can arbitrarily deviate. The HbC model is often the first, more tractable security goal for designing complex protocols like Secure Multi-Party Computation (MPC) or Secure Aggregation.
Passive Information Gathering
The adversary's threat is post-hoc analysis. After correctly executing their role, they record all protocol transcripts—every message sent and received—and apply unlimited computational power to infer secrets. For example, in a federated learning round, an HbC central server would correctly aggregate updates but might try to reverse-engineer an individual client's private training data from their model gradient. This makes defenses like additive secret sharing and pairwise masking essential, as they ensure the aggregated result reveals nothing about individual inputs.
Formal Analysis Foundation
The HbC model provides a well-defined, cryptographically rigorous framework for proving security. A protocol proven secure against HbC adversaries guarantees that no additional information is leaked beyond the protocol's intended output. This is typically proven via a simulation-based security argument: if anything an adversary learns can be simulated without access to private inputs, then the protocol is secure. This foundational proof is often a prerequisite before adding robustness against stronger, malicious adversaries.
Real-World Assumption
The model is considered a practical and realistic threat assumption for many enterprise and regulated environments. It models parties who have an incentive to follow the protocol (e.g., to maintain a service contract or comply with regulation) but also have an incentive to learn extra information (e.g., for competitive intelligence). It is frequently assumed in privacy-preserving machine learning architectures, including federated learning, where participants (hospitals, banks) are trusted to run code correctly but not to share raw data.
Limitations & Stronger Models
Security against HbC adversaries does not guarantee robustness against active attacks. Key limitations include:
- No protection against data poisoning: A malicious client could submit corrupted model updates.
- No protection against denial-of-service: Clients may simply drop out.
- Vulnerability to protocol deviations.
Therefore, for high-stakes deployments, protocols are often later strengthened to resist Malicious Adversaries or Byzantine failures, which are more complex and computationally expensive to defend against.
Relationship to Secure Aggregation
In Federated Learning, the central server is often treated as an Honest-but-Curious party. Secure Aggregation protocols like the Bonawitz Protocol are explicitly designed for this model. They allow the server to compute the sum of client updates (e.g., for Federated Averaging) without being able to inspect any single client's contribution. The server follows the aggregation steps correctly but is prevented from learning individual values through cryptographic techniques like masking with key agreement and dropout tolerance.
Honest-but-Curious vs. Other Adversary Models
A comparison of security assumptions and capabilities for different adversary models used in cryptographic protocol analysis and secure federated learning.
| Security Feature / Capability | Honest-but-Curious (Semi-Honest) | Malicious (Active) | Covert |
|---|---|---|---|
Adversarial Goal | Passively infer private data from protocol transcripts. | Actively compromise protocol integrity, availability, or privacy. | Cheat without being detected, but will stop if detection is likely. |
Protocol Deviation | Follows the protocol specification exactly. | Can arbitrarily deviate from the protocol (e.g., send false messages). | May deviate, but aims to avoid definitive proof of cheating. |
Primary Threat | Privacy violation through inference (e.g., model inversion). | Data/model poisoning, denial-of-service, privacy attacks. | Undetected privacy breaches or integrity violations. |
Formal Analysis Method | Simulation-based security proofs (ideal/real paradigm). | Stronger simulation proofs requiring abort or fairness. | Security with abort and explicit detection probability. |
Cryptographic Primitives Required | Secure Multi-Party Computation (MPC), Homomorphic Encryption. | Byzantine Fault Tolerance, Verifiable Computation, ZKPs. | Commitment schemes, cut-and-choose, proofs of misbehavior. |
Assumed Trust in Participants | Participants are trusted to execute code correctly. | No trust in participants' adherence to the protocol. | Limited trust; assumes deterrence by detection risk. |
Common Use Case in Federated Learning | Baseline privacy analysis for Secure Aggregation. | Byzantine-robust aggregation, defense against poisoning. | Settings with reputational costs, like cross-silo FL. |
Computational & Communication Overhead | Moderate (e.g., for MPC or HE). | High (e.g., for robust aggregation or extensive ZKPs). | Variable, often high due to detection mechanisms. |
Protocols Designed for Honest-but-Curious Security
These cryptographic protocols and techniques are engineered to function correctly under the honest-but-curious (semi-honest) adversary model, where all participants follow the protocol but may attempt to infer private information from the messages they observe.
Additive Homomorphic Encryption
Additive Homomorphic Encryption is an encryption scheme where performing an operation (like addition) on ciphertexts produces a new ciphertext that, when decrypted, equals the sum of the corresponding plaintexts. This is ideal for honest-but-curious aggregation.
- Core Mechanism: Enables a server to compute the sum of encrypted client updates without ever decrypting them individually.
- Primary Use Case: The foundation for many secure aggregation protocols in federated learning.
- Example Schemes: The Paillier cryptosystem is a widely used public-key scheme offering additive homomorphism.
- Limitation: Typically supports only addition, not arbitrary computations, making it efficient for specific aggregation tasks.
Secret Sharing
Secret Sharing is a method for distributing a secret among a group of participants, where each is allocated a share. The secret can only be reconstructed when a sufficient number of shares are combined. Under honest-but-curious assumptions, individual shares reveal zero information about the secret.
- Threshold Schemes: Shamir's Secret Sharing is a common (t, n)-threshold scheme where any 't' of 'n' shares can reconstruct the secret.
- Application in Secure Aggregation: A client's model update can be split into shares sent to multiple servers. The sum of updates is computed across shares, and no single server sees any client's full contribution.
- Verifiable Secret Sharing (VSS): An extension that allows participants to verify the validity of their shares, adding robustness against a malicious dealer, even in a semi-honest participant model.
Differential Privacy Mechanisms
Differential Privacy provides a mathematically rigorous guarantee that the presence or absence of any single individual's data in a dataset has a negligible effect on the output of an analysis. When applied locally, it defends against honest-but-curious aggregators.
- Local Model: In Local Differential Privacy, each client perturbs its data locally before sending it to the server. The server sees only noisy data, providing privacy even if the server is curious.
- Common Mechanisms:
- Laplace Mechanism: Adds noise drawn from a Laplace distribution to numerical outputs.
- Gaussian Mechanism: Adds Gaussian noise, often used when the output is a high-dimensional vector like a gradient.
- Privacy Budget (ε): Governs the privacy-utility trade-off. A smaller epsilon (ε) means stronger privacy but noisier results.
The Bonawitz Secure Aggregation Protocol
The Bonawitz Protocol (often termed Practical Secure Aggregation) is a specific cryptographic protocol designed for federated learning that provides secure aggregation under the honest-but-curious server model with dropout tolerance.
- Core Technique: Uses pairwise masking via a key agreement protocol (like Diffie-Hellman). Each client adds a secret mask to its update, shared with another client. When all clients submit updates, the masks cancel out in the sum.
- Dropout Resilience: If a client drops out, its pairwise mask cannot be canceled. The protocol uses a trusted third party or secret sharing to a committee of servers to recover the necessary masking keys.
- Security Guarantee: The central server learns only the aggregated model update, not any individual contribution, as long as clients follow the protocol and do not collude.
Trusted Execution Environments
A Trusted Execution Environment is a secure, isolated area within a main processor (e.g., an Intel SGX enclave) that guarantees code integrity and data confidentiality. It can enforce honest-but-curious execution by design.
- How it Works: Sensitive code (e.g., aggregation logic) runs inside the TEE. Even the host operating system or cloud provider cannot observe or tamper with the data being processed.
- Use Case: A federated learning server can run inside a TEE. Clients encrypt their updates for the TEE's specific key. The TEE decrypts, aggregates, and outputs only the final model, with the internal process hidden from the curious server operator.
- Trust Assumption: Shifts trust from the entire server software stack to the hardware manufacturer's implementation of the TEE and the remote attestation process.
Implications for Federated Learning & Secure Aggregation
The Honest-but-Curious (HbC) adversary model defines a foundational threat assumption for designing privacy-preserving protocols in federated learning and secure aggregation.
An Honest-but-Curious (HbC) adversary, also called a semi-honest adversary, is a participant in a protocol who follows the prescribed steps correctly but may later analyze all received messages to infer private information about other participants. In federated learning, this models a central aggregation server or a compromised client that executes the training and aggregation protocol faithfully but attempts to learn sensitive details from individual model updates. This assumption is critical because it represents a realistic, low-overhead threat for many commercial and regulated environments where participants have an incentive to maintain system functionality but also to gain a competitive or informational advantage.
For Secure Aggregation, protocols must be designed to guarantee that even an HbC aggregator learns only the sum of client updates, not any individual contribution. This is typically achieved using cryptographic techniques like additive secret sharing and pairwise masking, as in the Bonawitz protocol. The HbC model simplifies protocol design compared to a malicious adversary model, enabling more efficient systems. However, it necessitates complementary defenses, such as differential privacy, to protect against inference attacks on the aggregated sum itself, ensuring robust privacy in federated edge learning systems.
Frequently Asked Questions
An Honest-but-Curious (HbC) adversary, also known as a semi-honest adversary, is a foundational security model in cryptography and privacy-preserving machine learning. It defines a participant who follows the protocol's instructions correctly but may later attempt to infer private information from the messages they legitimately receive during execution.
An Honest-but-Curious (HbC) adversary is a security model where a protocol participant follows the prescribed algorithm correctly but may passively record and analyze all intermediate messages they receive to learn additional, private information beyond the intended output. This model assumes the adversary does not deviate from the protocol steps, inject malicious data, or disrupt communication. It is the standard baseline for analyzing privacy in systems like Secure Multi-Party Computation (MPC) and Federated Learning, where the goal is to prevent information leakage even when all parties execute the code as written. The term 'semi-honest' is synonymous.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
The Honest-but-Curious adversary model is foundational within a broader ecosystem of cryptographic protocols and security assumptions. These related concepts define the threat landscape and the tools used to defend against it.
Malicious Adversary Model
A stronger security model where participants can arbitrarily deviate from the protocol specification. Unlike an Honest-but-Curious adversary, a malicious adversary can:
- Send incorrect or fabricated messages.
- Drop out of the protocol mid-execution.
- Collude with other participants.
Protocols secure against malicious adversaries are significantly more complex and computationally expensive but provide guarantees against active sabotage.
Secure Multi-Party Computation (MPC)
A cryptographic subfield that enables multiple parties to jointly compute a function over their private inputs while revealing only the final output. MPC protocols are often designed to be secure against specific adversary models, including Honest-but-Curious.
Key Property: Privacy is maintained even if some participants are curious about others' data. MPC is the theoretical foundation for many privacy-preserving techniques, including secure aggregation in federated learning.
Differential Privacy
A rigorous mathematical framework for quantifying and limiting privacy loss. It provides a guarantee that the inclusion or exclusion of any single individual's data has a negligible effect on the algorithm's output.
Relation to HBC: While HBC defines who might try to learn (a protocol-following participant), Differential Privacy provides a mechanism to mathematically bound what they can learn, even if they have access to aggregated results. They are often used in tandem.
Trusted Execution Environment (TEE)
A secure, isolated area within a main processor (e.g., Intel SGX, ARM TrustZone) that guarantees the confidentiality and integrity of code and data loaded inside it.
Alternative to Cryptographic Protocols: A TEE can be used to create a trusted aggregator, effectively reducing the threat model. The server is assumed to be honest inside the enclave, even if the host OS is compromised. This shifts trust from pure cryptography to hardware security, offering a different trade-off for mitigating curious adversaries.
Byzantine Robust Aggregation
Algorithms designed for secure aggregation in the presence of malicious clients. While HBC adversaries only observe, Byzantine clients can actively corrupt their updates.
Examples: Krum, Median, and Trimmed Mean are aggregation rules that filter out statistical outliers. These techniques are often layered on top of secure aggregation protocols to defend against a stronger threat model that includes both curious and malicious actors.
Zero-Knowledge Proof (ZKP)
A cryptographic protocol where one party (the prover) can prove to another (the verifier) that a statement is true without revealing any information beyond the statement's validity.
Application to HBC: In federated learning, a client could use a ZKP to prove to the server that their local update was computed correctly (e.g., on valid, non-poisoned data) without revealing the update itself. This enhances verifiability within the semi-honest model, ensuring participants are not just curious but also correctly following the computational steps.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us