mirror of
https://github.com/calofmijuck/blog.git
synced 2025-12-06 14:53:50 +00:00
* [PUBLISHER] upload files #175 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-19-symmetric-key-encryption.md * [PUBLISHER] upload files #177 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-19-symmetric-key-encryptio.md * [PUBLISHER] upload files #178 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #179 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #180 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #181 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #182 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * [PUBLISHER] upload files #183 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #184 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #185 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #186 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * [PUBLISHER] upload files #187 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 14. Secure Multiparty Computation.md * DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #188 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 14. Secure Multiparty Computation.md * DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md * chore: remove files * [PUBLISHER] upload files #197 * PUSH NOTE : 수학 공부에 대한 고찰.md * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 04. Measurable Functions.md * PUSH ATTACHMENT : mt-04.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 02. Construction of Measure.md * PUSH ATTACHMENT : mt-02.png * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * PUSH NOTE : Rules of Inference with Coq.md * PUSH NOTE : 블로그 이주 이야기.md * PUSH NOTE : Secure IAM on AWS with Multi-Account Strategy.md * PUSH ATTACHMENT : separation-by-product.png * PUSH NOTE : You and Your Research, Richard Hamming.md * PUSH NOTE : 10. Digital Signatures.md * PUSH ATTACHMENT : mc-10-dsig-security.png * PUSH ATTACHMENT : mc-10-schnorr-identification.png * PUSH NOTE : 9. Public Key Encryption.md * PUSH ATTACHMENT : mc-09-ss-pke.png * PUSH NOTE : 8. Number Theory.md * PUSH NOTE : 7. Key Exchange.md * PUSH ATTACHMENT : mc-07-dhke.png * PUSH ATTACHMENT : mc-07-dhke-mitm.png * PUSH ATTACHMENT : mc-07-merkle-puzzles.png * PUSH NOTE : 6. Hash Functions.md * PUSH ATTACHMENT : mc-06-merkle-damgard.png * PUSH ATTACHMENT : mc-06-davies-meyer.png * PUSH ATTACHMENT : mc-06-hmac.png * PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md * PUSH ATTACHMENT : mc-05-ci.png * PUSH ATTACHMENT : mc-05-etm-mte.png * PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md * PUSH ATTACHMENT : mc-01-prg-game.png * PUSH ATTACHMENT : mc-01-ss.png * PUSH NOTE : 4. Message Authentication Codes.md * PUSH ATTACHMENT : mc-04-mac.png * PUSH ATTACHMENT : mc-04-mac-security.png * PUSH ATTACHMENT : mc-04-cbc-mac.png * PUSH ATTACHMENT : mc-04-ecbc-mac.png * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH ATTACHMENT : is-03-ecb-encryption.png * PUSH ATTACHMENT : is-03-cbc-encryption.png * PUSH ATTACHMENT : is-03-ctr-encryption.png * PUSH NOTE : 2. PRFs, PRPs and Block Ciphers.md * PUSH ATTACHMENT : mc-02-block-cipher.png * PUSH ATTACHMENT : mc-02-feistel-network.png * PUSH ATTACHMENT : mc-02-des-round.png * PUSH ATTACHMENT : mc-02-DES.png * PUSH ATTACHMENT : mc-02-aes-128.png * PUSH ATTACHMENT : mc-02-2des-mitm.png * PUSH NOTE : 18. Bootstrapping & CKKS.md * PUSH NOTE : 17. BGV Scheme.md * PUSH NOTE : 16. The GMW Protocol.md * PUSH ATTACHMENT : mc-16-beaver-triple.png * PUSH NOTE : 15. Garbled Circuits.md * PUSH NOTE : 14. Secure Multiparty Computation.md * PUSH NOTE : 13. Sigma Protocols.md * PUSH ATTACHMENT : mc-13-sigma-protocol.png * PUSH ATTACHMENT : mc-13-okamoto.png * PUSH ATTACHMENT : mc-13-chaum-pedersen.png * PUSH ATTACHMENT : mc-13-gq-protocol.png * PUSH NOTE : 12. Zero-Knowledge Proofs (Introduction).md * PUSH ATTACHMENT : mc-12-id-protocol.png * PUSH NOTE : 11. Advanced Topics.md * PUSH NOTE : 0. Introduction.md * PUSH NOTE : 02. Symmetric Key Cryptography (1).md * PUSH NOTE : 09. Transport Layer Security.md * PUSH ATTACHMENT : is-09-tls-handshake.png * PUSH NOTE : 08. Public Key Infrastructure.md * PUSH ATTACHMENT : is-08-certificate-validation.png * PUSH NOTE : 07. Public Key Cryptography.md * PUSH NOTE : 06. RSA and ElGamal Encryption.md * PUSH NOTE : 05. Modular Arithmetic (2).md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * PUSH ATTACHMENT : is-03-feistel-function.png * PUSH ATTACHMENT : is-03-cfb-encryption.png * PUSH ATTACHMENT : is-03-ofb-encryption.png * PUSH NOTE : 04. Modular Arithmetic (1).md * PUSH NOTE : 01. Security Introduction.md * PUSH ATTACHMENT : is-01-cryptosystem.png * PUSH NOTE : Search Time in Hash Tables.md * PUSH NOTE : 랜덤 PS일지 (1).md * chore: rearrange articles * feat: fix paths * feat: fix all broken links * feat: title font to palatino
189 lines
12 KiB
Markdown
189 lines
12 KiB
Markdown
---
|
|
share: true
|
|
toc: true
|
|
math: true
|
|
categories:
|
|
- Lecture Notes
|
|
- Modern Cryptography
|
|
path: _posts/lecture-notes/modern-cryptography
|
|
tags:
|
|
- lecture-note
|
|
- cryptography
|
|
- security
|
|
title: 14. Secure Multiparty Computation
|
|
date: 2023-11-09
|
|
github_title: 2023-11-09-secure-mpc
|
|
---
|
|
|
|
## Secure Multiparty Computation (MPC)
|
|
|
|
Suppose we have a function $f$ that takes $n$ inputs and produces $m$ outputs.
|
|
|
|
$$
|
|
(y _ 1, \dots, y _ m) = f(x _ 1, \dots, x _ n).
|
|
$$
|
|
|
|
$N$ parties $P _ 1, \dots, P _ N$ are trying to evaluate this function with a protocol. Each $x _ i$ is submitted by one of the parties, and each output $y _ j$ will be given to one or more parties.
|
|
|
|
In **secure multiparty computation** (MPC), we wish to achieve some security functionalities.
|
|
|
|
- **Privacy**: no party learns anything about any other party's inputs, except for the information in the output.
|
|
- **Soundness**: honest parties compute correct outputs.
|
|
- **Input independence**: all parties must choose their inputs independently of other parties' inputs.
|
|
|
|
Security must hold even if there is any adversarial behavior in the party.
|
|
|
|
### Example: Secure Summation
|
|
|
|
Suppose we have $n$ parties $P _ 1, \dots, P _ n$ with private values $x _ 1, \dots, x _ n$. We would like to *securely* compute the sum $s = x _ 1 + \cdots + x _ n$.
|
|
|
|
> 1. Choose $M$ large enough so that $M > s$.
|
|
> 2. $P _ 1$ samples $r \la \Z _ M$ and computes $s _ 1 = r + x _ 1 \pmod M$ and sends it to $P _ 2$.
|
|
> 3. In the same manner, $P _ i$ computes $s _ i = s _ {i-1} + x _ i \pmod M$ and sends it to $P _ {i+1}$.
|
|
> 4. As the final step, $s _ n$ is returned to $P _ 1$, where he outputs $s = s _ n - r \pmod M$.
|
|
|
|
This protocol seems secure since $r$ is a random noise added to the actual partial sum. But the security actually depends on how we model adversarial behavior.
|
|
|
|
Consider the case where parties $P _ 2$ and $P _ 4$ team up (collusion). These two can share information between them. They have the following:
|
|
|
|
- $P _ 2$ has $s _ 1$, $s _ 2$, $x _ 2$.
|
|
- $P _ 4$ has $s _ 3$, $s _ 4$, $x _ 4$.
|
|
|
|
Using $s _ 2$ and $s _ 3$, they can compute $x _ 3 = s _ 3 - s _ 2$ and obtain the input of $P _ 3$. This violates privacy. Similarly, if $P _ i$ and $P _ j$ team up, the can compute the partial sum
|
|
|
|
$$
|
|
s _ {j - 1} - s _ {i} = x _ {i+1} + \cdots + x _ {j-1}
|
|
$$
|
|
|
|
which leaks information about the inputs of $P _ {i+1}, \dots, P _ {j-1}$.
|
|
|
|
## Modeling Adversaries for Multiparty Computation
|
|
|
|
The adversary can decide not to follow the protocol and perform arbitrarily.
|
|
|
|
- **Semi-honest** adversaries follows the protocol and tries to learn more information by inspecting the communication.
|
|
- **Malicious** adversaries can behave in any way, unknown to us.
|
|
|
|
Semi-honest adversaries are similar to *passive* adversaries, whereas malicious adversaries are similar to *active* adversaries.
|
|
|
|
We can also model the **corruption strategy**. Some parties can turn into an adversary during the protocol.
|
|
|
|
- In **static** corruptions, the set of adversarial parties is fixed throughout the execution.
|
|
- In **adaptive** corruptions, the adversary corrupts parties during the execution, based on the information gained from the protocol execution.
|
|
|
|
We can decide how much computational power to give to the adversary. For *computational security*, an adversary must be efficient, only polynomial time strategies are allowed. For *information-theoretic security*, an adversary has unbounded computational power.
|
|
|
|
We will only consider **semi-honest** adversaries with **static** corruptions.
|
|
|
|
## Defining Security for Multiparty Computation
|
|
|
|
The idea is the following.
|
|
|
|
> An attack on the protocol in the **real world** is equivalent to some attack on the protocol in an **ideal world** in which no damage can be done.
|
|
|
|
In the **ideal world**, we use a trusted party to implement a protocol. All parties, both honest and corrupted, submit their input to the trusted party. Since the trusted party is not corrupted, the protocol is safe.
|
|
|
|
In the **real world**, there is no trusted party and parties must communicate with each other using a protocol.
|
|
|
|
Thus, a secure protocol must provide security in the real world that is equivalent to that in the ideal world. The definition is saying the following: **there is no possible attack in the ideal world, so there is no possible attack in the real world**. This kind of definition implies privacy, soundness and input independence.
|
|
|
|
> For every efficient adversary $\mc{A}$ in the real world, there exists an *equivalent* efficient adversary $\mc{S}$ (usually called a **simulator**) in the ideal world.
|
|
|
|
### Semi-Honest & Static Corruption
|
|
|
|
- The *view* of a party consists of its input, random tape and the list of messages obtained from the protocol.
|
|
- The view of an adversary is the union of views of corrupted parties.
|
|
- If an adversary learned anything from the protocol, it must be efficiently computable from its view.
|
|
- If a protocol is secure, it must be possible in the ideal world to generate something indistinguishable from the real world adversary's view.
|
|
- In the ideal world, the adversary's view consists of inputs/outputs to and from the trusted party.
|
|
- An adversary in the ideal world must be able to generate a view equivalent to the real world view. We call this ideal world adversary a **simulator**.
|
|
- If we show the existence of a simulator, a real world adversary's ability is the same as an adversary in the ideal world.
|
|
|
|
> **Definition.** Let $\mc{A}$ be the set of parties that are corrupted, and let $\rm{Sim}$ be a simulator algorithm.
|
|
> - $\rm{Real}(\mc{A}; x _ 1, \dots, x _ n)$: each party $P _ i$ runs the protocol with private input $x _ i$. Let $V _ i$ be the final view of $P _ i$. Output $\braces{V _ i : i \in \mc{A}}$.
|
|
> - $\rm{Ideal} _ \rm{Sim}(x _ 1, \dots, x _ n)$: output $\rm{Sim}(\mc{A}; \braces{(x _ i, y _ i) : i \in \mc{A}})$.
|
|
>
|
|
> A protocol is **secure against semi-honest adversaries** if there exists a simulator such that for every subset of corrupted parties $\mc{A}$, its views in the real and ideal worlds are indistinguishable.
|
|
|
|
## Oblivious Transfer (OT)
|
|
|
|
This is a building block for building any MPC.
|
|
|
|
Suppose that the sender has data $m _ 1, \dots, m _ n \in \mc{M}$, and the receiver has an index $i \in \braces{1, \dots, n}$. The sender wants to send exactly one message and hide others. Also, the receiver wants to hide which message he received.
|
|
|
|
This problem is called 1-out-of-$n$ **oblivious transfer** (OT).
|
|
|
|
### 1-out-of-2 OT Construction from ElGamal Encryption
|
|
|
|
We show an example of 1-out-of-2 OT using the ElGamal encryptions scheme. We use a variant where a hash function is used in encryption.
|
|
|
|
It is known that $k$-out-of-$n$ OT is constructible from 1-out-of-2 OTs.
|
|
|
|
> Suppose that the sender Alice has messages $x _ 0, x _ 1 \in \braces{0, 1}\conj$, and the receiver Bob has a choice $\sigma \in \braces{0, 1}$.
|
|
>
|
|
> 1. Bob chooses $sk = \alpha \la \Z _ q$ and computes $h = g^\alpha$, and chooses $h' \la G$.
|
|
> 2. Bob sets $pk _ \sigma = h$ and $pk _ {1-\sigma} = h'$ and sends $(pk _ 0, pk _ 1)$ to Alice.
|
|
> 3. Alice encrypts each $x _ i$ using $pk _ i$, obtains two ciphertexts.
|
|
> - $\beta _ 0, \beta _ 1 \la \Z _ q$.
|
|
> - $c _ 0 = \big( g^{\beta _ 0}, H(pk _ 0^{\beta _ 0}) \oplus x _ 0 \big)$, $c _ 1 = \big( g^{\beta _ 1}, H(pk _ 1^{\beta _ 1}) \oplus x _ 1 \big)$.
|
|
> 4. Alice sends $(c _ 0, c _ 1)$ to Bob.
|
|
> 5. Bob decrypts $c _ \sigma$ with $sk$ to get $x _ \sigma$.
|
|
|
|
Correctness is obvious.
|
|
|
|
Alice's view contains the following: $x _ 0, x _ 1, pk _ 0, pk _ 1, c _ 0, c _ 1$. Among these, $pk _ 0, pk _ 1$ are the received values from Bob. But these are random group elements, so she learns nothing about $\sigma$. The simulator can choose two random group elements to simulate Alice.
|
|
|
|
Bob's view contains the following: $\sigma, \alpha, g^\alpha, h', c _ 0, c _ 1, x _ \sigma$. He only knows one private key, so he only learns $x _ \sigma$, under the DL assumption. (He doesn't have the discrete logarithm for $h'$) The simulator must simulate $c _ 0, c _ 1$, so it encrypts $x _ \sigma$ with $pk _ \sigma$, and as for $x _ {1-\sigma}$, a random message is encrypted with $pk _ {1-\sigma}$. This works because the encryption scheme is semantically secure, meaning that it doesn't reveal any information about the underlying message.
|
|
|
|
The above works for **semi-honest** parties. To prevent malicious behavior, we fix the protocol a bit.
|
|
|
|
> 1. Alice sends a random $w \la G$ first.
|
|
> 2. Bob must choose $h$ and $h'$ so that $hh' = w$. $h$ is chosen the same way, and $h' = wh\inv$ is computed.
|
|
>
|
|
> The remaining steps are the same, except that Alice checks if $pk _ 0 \cdot pk _ 1 = w$.
|
|
|
|
Bob must choose $h, h'$ such that $hh' = w$. If not, Bob can choose $\alpha' \la \Z _ q$ and set $h' = g^{\alpha'}$, enabling him to decrypt both $c _ 0, c _ 1$, revealing $x _ 0, x _ 1$. Under the DL assumption, Bob cannot find the discrete logarithm of $h'$, which prevents malicious behavior.
|
|
|
|
### 1-out-of-$n$ OT Construction from ElGamal Encryption
|
|
|
|
Let $m _ 1, \dots, m _ n \in \mc{M}$ be the messages to send, and let $i$ be an index. We will use ElGamal encryption on a cyclic group $G = \span{g}$ of prime order, with a hash function and a semantically secure symmetric cipher $(E _ S, D _ S)$.
|
|
|
|
> 1. Alice chooses $\beta \la \Z _ q$, computes $v \la g^\beta$ and sends $v$ to Bob.
|
|
> 2. Bob chooses $\alpha \la \Z _ q$, computes $u \la g^\alpha v^{-i}$ and sends $u$ to Alice.
|
|
> 3. For $j = 1, \dots, n$, Alice computes the following.
|
|
> - Compute $u _ j \la u \cdot v^j = g^\alpha v^{j-i}$ as the public key for the $j$-th message.
|
|
> - Encrypt $m _ j$ as $(g^\beta, c _ j)$, where $c _ j \la E _ S\big( H(g^\beta, u _ j^\beta), m _ j \big)$.
|
|
> 4. Alice sends $(c _ 1, \dots, c _ n)$ to Bob.
|
|
> 5. Bob decrypts $c _ i$ as follows.
|
|
> - Compute symmetric key $k \la H(v, v^\alpha)$ where $v = g^\beta$ from step $1$.
|
|
> - $m _ i \la D _ S(k, c _ i)$.
|
|
|
|
Note that all ciphertexts $c _ j$ were created from the same ephemeral key $\beta \in \Z _ q$.
|
|
|
|
For correctness, we check that Bob indeed receives $m _ i$ from the above protocol. Check that $u _ i = u\cdot v^i = g^\alpha v^0 = g^\alpha$, then $u _ i^\beta = g^{\alpha\beta} = v^\alpha$. Since $c _ i = E _ S\big( H(g^\beta, u _ i^\beta), m _ i \big) = E _ S\big( H(v, v^\alpha), m _ i \big)$, the decryption gives $m _ i$.
|
|
|
|
Now is this oblivious? All that Alice sees is $u = g^\alpha v^{-i}$ from Bob. Since $\alpha \la \Z _ q$, $u$ is uniformly distributed over elements of $G$. Alice learns no information about $i$.
|
|
|
|
As for Bob, we need the **CDH assumption**. Suppose that Bob can query $H$ on two different ciphertexts $c _ {j _ 1}, c _ {j _ 2}$. Then he knows
|
|
|
|
$$
|
|
u _ {j _ 1}^\beta/u _ {j _ 2}^\beta = v^{\beta(j _ 1 - j _ 2)},
|
|
$$
|
|
|
|
and by raising both to the $(j _ 1 - j _ 2)\inv$ power (inverse in $\Z _ q$), he can compute $v^\beta = g^{\beta^2}$. Thus, Bob has computed $g^{\beta^2}$ from $g^\beta$, and this breaks the CDH assumption.[^1] Thus Bob cannot query $H$ on two points, and is unable to decrypt two ciphertexts. He only learns $m _ i$.
|
|
|
|
### OT for Computing $2$-ary Function with Finite Domain
|
|
|
|
We can use an OT for computing a $2$-ary function with finite domain.
|
|
|
|
Let $f : X _ 1 \times X _ 2 \ra Y$ be a deterministic function with $X _ 1$, $X _ 2$ both finite. There are two parties $P _ 1, P _ 2$ with inputs $x _ 1, x _ 2$, and they want to compute $f(x _ 1, x _ 2)$ without revealing their input.
|
|
|
|
Then we can use $1$-out-of-$\abs{X _ 2}$ OT to securely compute $f(x _ 1, x _ 2)$. Without loss of generality, suppose that $P _ 1$ is the sender.
|
|
|
|
$P _ 1$ computes $y _ x =f(x _ 1, x)$ for all $x \in X _ 2$, resulting in $\abs{X _ 2}$ messages. Then $P _ 1$ performs 1-out-of-$\abs{X _ 2}$ OT with $P _ 2$. The value of $x _ 2$ will be used as the choice of $P _ 2$, which will be oblivious to $P _ 1$.[^2]
|
|
|
|
This method is inefficient, so we have better methods!
|
|
|
|
[^1]: Given $g^\alpha, g^\beta$, compute $g^{\alpha + \beta}$. Then compute $g^{\alpha^2}, g^{\beta^2}, g^{(\alpha+\beta)^2}$, and obtain $g^{2\alpha\beta}$. Exponentiate by $2\inv \in \Z _ q$ to find $g^{\alpha\beta}$.
|
|
[^2]: Can $P _ 1$ learn the value of $x _ 2$ from the final output $y _ {x _ 2} = f(x _ 1, x _ 2)$?
|