Zero-Knowledge Proof (ZKP)

The protocol must function correctly when both parties are honest. If the statement is true and the prover follows the protocol, the verifier will always be convinced of its truth.

• Guarantee: An honest prover can always convince an honest verifier.
• Mechanism: Relies on the deterministic logic of the underlying cryptographic circuit.
• Example: If a prover knows the private key corresponding to a public key, a correct ZKP protocol will never falsely reject their proof.

A malicious prover cannot convince the verifier of a false statement, except with negligible probability. This property binds the proof to mathematical reality.

• Guarantee: No efficient adversary can forge a proof for an invalid statement.
• Types:
  • Computational Soundness: Security holds against bounded adversaries (used in zk-SNARKs).
  • Statistical Soundness: Security holds against unbounded adversaries.
• Example: A prover who does not know the pre-image of a hash cannot generate a valid proof that they do.

The verifier learns absolutely nothing beyond the single bit of information: 'the statement is true.' No secret data is leaked during the interaction.

• Guarantee: The verifier cannot extract any knowledge about the prover's private witness.
• Simulation Paradigm: For any verifier, there exists a simulator that can produce a transcript indistinguishable from a real interaction without access to the secret.
• Example: Proving you are over 18 without revealing your exact birth date. The verifier learns only the boolean result.

While not a core theoretical property like the three above, succinctness is a practical requirement for modern ZKP systems like zk-SNARKs. It ensures the proof is small and fast to verify.

• Proof Size: Logarithmic or constant size relative to the computation (e.g., a few hundred bytes).
• Verification Time: Often constant or logarithmic, taking milliseconds regardless of the computation's complexity.
• Contrast: Older systems (like zk-STARKs without recursion) have larger proofs but remove the need for a trusted setup.

A stronger notion than soundness. It demonstrates that the prover not only asserts a true statement but actually possesses the secret witness that makes the statement true.

• Extractor: A theoretical algorithm exists that can extract the witness by interacting with a successful prover.
• Distinction: Soundness prevents proving false statements; Proof of Knowledge prevents proving a statement without knowing why it's true.
• Relevance: Essential for authentication systems where possession of a secret key must be cryptographically guaranteed.

Transforms an interactive protocol (requiring back-and-forth challenges) into a single message from prover to verifier. This is achieved via the Fiat-Shamir heuristic.

• Mechanism: Replaces the verifier's random challenges with the output of a cryptographic hash function applied to the transcript.
• Advantage: Enables asynchronous verification and blockchain scalability, as proofs can be verified by anyone at any time.
• Standard: Most practical ZKPs (zk-SNARKs, zk-STARKs) are Non-Interactive Zero-Knowledge proofs.

Zero-Knowledge Succinct Non-Interactive Argument of Knowledge is the most widely deployed ZKP variant in production systems. It generates constant-size proofs (typically < 300 bytes) that can be verified in milliseconds, regardless of the complexity of the statement being proven.

• Requires a trusted setup phase to generate common reference strings
• Proof generation is computationally intensive but verification is extremely fast
• Used in blockchain privacy protocols and increasingly in verifiable computation for healthcare analytics
• The succinctness property makes it ideal for resource-constrained verifiers like edge devices

A cryptographic protocol enabling multiple parties to jointly compute a function over their private inputs while ensuring that no party learns anything beyond the designated output.

• Complements ZKPs: SMPC hides inputs during computation; ZKPs prove correctness of the computation
• In cross-silo healthcare settings, enables collaborative risk scoring across hospitals without pooling patient data
• Typically uses secret sharing to distribute data fragments among participants
• Higher communication overhead than ZKP-based approaches but provides information-theoretic security in some constructions

A cryptographic primitive that allows computations directly on encrypted ciphertexts, producing an encrypted result that decrypts to the correct plaintext output.

• Fully Homomorphic Encryption (FHE) supports arbitrary computations (unlimited additions and multiplications)
• ZKPs can prove that HE computations were performed correctly without revealing the encrypted inputs
• The combination of ZKPs + HE enables private smart contracts and confidential medical AI inference
• Current limitation: FHE remains orders of magnitude slower than plaintext computation, making ZKP-based verifiability a more practical alternative for many use cases

A hardware-enforced isolated area within a main processor that guarantees the confidentiality and integrity of code and data loaded inside it.

• Protects sensitive computation from the host operating system, hypervisor, and cloud provider
• Attestation cryptographically proves to remote parties that genuine code is running in a secure enclave
• ZKPs provide mathematical guarantees independent of hardware trust assumptions, while TEEs rely on silicon vendor security
• Hybrid architectures combine TEEs for performance with ZKPs for hardware-independent verifiability in healthcare compliance scenarios

A mathematical framework that quantifies the privacy guarantee provided by a randomized algorithm, ensuring that outputs do not reveal whether any single individual's data was included.

• Defined by the privacy loss parameter epsilon (ε): smaller values indicate stronger privacy
• ZKPs and differential privacy address complementary threat models: ZKPs protect computation integrity, differential privacy protects individual contributions in aggregate outputs
• In federated learning, differential privacy noise is often added to model updates before ZKP-based verification
• The privacy budget must be carefully managed across multiple queries to prevent cumulative leakage