diff --git a/Untitled 2.md b/Untitled 2.md new file mode 100644 index 0000000..f2bc37d --- /dev/null +++ b/Untitled 2.md @@ -0,0 +1,120 @@ +## HMAC + +This definition is taken from [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104): + +$$ +\begin{align} +\operatorname{HMAC}(K, m) &= \operatorname{H}\Bigl(\bigl(K' \oplus opad\bigr) \parallel +\operatorname{H} \bigl(\left(K' \oplus ipad\right) \parallel m\bigr)\Bigr) \\ +K' &= \begin{cases} +\operatorname{H}\left(K\right) & \text{if}\ K\text{ is larger than block size} \\ +K & \text{otherwise} +\end{cases} +\end{align} +$$ + +where: + +- `H` is a cryptographic hash function. +- `m` is the message to be authenticated. +- `K` is the secret key. +- `K'` is a block-sized key derived from the secret key, either by padding to the right with 0s up to the block size, or by hashing down to less than or equal to the block size first and then padding to the right with zeros. +- $\parallel$ denotes `concatenation`. +- $\oplus$ denotes bitwise `exclusive or` (XOR). +- `opad` is the block-sized outer padding, consisting of repeated bytes valued `0x5c`. +- `ipad` is the block-sized inner padding, consisting of repeated bytes valued `0x36`. + +## GSW Homomorphic Commitment Scheme + +[View this for details](docs/gsw_fhe_scheme.md) + +# The Solution + +## Setup Phase (performed by a trusted party) + +1. **Prepare for the GSW Commitment Scheme:** + - Generate a uniformly random matrix $A$ needed in both the commitment and verification phases. + +2. **Generate Commitments for the `bot_token`:** + - First, calculate: + $$ + \{b = \text{Sha256}(\operatorname{bot\_token})\} \in \{0, 1\}^{256} + $$ + where $b$ is the binary form of the hash value of the `bot_token`. + - Then, commit each bit of $b$: + $$ + \{cb_i, rb_i\} = \operatorname{Commit}(A, b_i); \forall i \in \{1, 2, \ldots, 256\} + $$ + where $cb_i = A \times rb_i + b_i \times G$, with $G$ being the gadget matrix. + - Prepare two more commitments for bit $0$ and bit $1$: + $$ + \{c0, r0\} = \operatorname{Commit}(A, 0) + $$ + $$ + \{c1, r1\} = \operatorname{Commit}(A, 1) + $$ + - Finally, publish $c0, r0, c1, r1, A, \{c_i, r_i\}; \forall i \in \{1, 2, \ldots, 256\}$. + +## Proving Phase + +1. **User Authentication and Information Commitment:** + - After successful authentication, Telegram provides the prover with user info, including _id_, _first_name_, _last_name_, _username_, _photo_url_, and _auth_date_ fields: + $$ + \operatorname{info} = \{0,1\}^n + $$ + where $n$ is the bit-length of the info, and: + $$ + sig = \operatorname{Hmac}(\text{bot\_token}, \operatorname{info}) = \{0, 1\}^{256} + $$ + - The prover then commits to the $\operatorname{user\_info}$ by mapping each bit of the user info with the commitment already published: + $$ + \{cu_i, ru_i\} = + \begin{cases} + \{c0, r0\} & \text{if info}_i = 0 \\ + \{c1, r1\} & \text{if info}_i = 1 + \end{cases}; \forall i \in \{1, 2, \ldots, n\} + $$ +2. **Opening Computation:** + - Assume there exists an algorithm $\operatorname{Open}()$ that, without knowing the $\text{bot\_token}$, can compute the opening $r_i$ for each output of 256 bits (using the "Input-dependent Evaluation" technique). The prover calculates: + $$ + r = \{r_i; \forall i \in \{1, 2, \ldots, 256\} \} = \operatorname{Open}(ru, rb, \text{info}) + $$ + - The prover then sends $cu, r, \text{info}, \text{sig}$ to the verifier. + +## Verification Phase + +1. **Hmac Commitment Computation:** + - The verifier computes the "Hmac" commitment $c$ using the "Input-Independent Evaluation" technique: + $$ + c = \{c_i; \forall i \in \{1, 2, \ldots, 256\} \} = Hmac_e(cu, cb) + $$ + where $Hmac_e$ is an equivalence algorithm to compute Hmac on the committed commitments. +2. **Commitment Check:** + - The verifier checks whether: + $$ + c_i \stackrel{?}{=} A \times r_i + \text{sig}_i \times G; \forall i \in \{1, 2, \ldots, 256\} + $$ + - The verifier then checks the consistency of the user's info: + $$ + cu_i \stackrel{?}{=} + \begin{cases} + c0 & \text{if info}_i = 0 \\ + c1 & \text{if info}_i = 1 + \end{cases}; \forall i \in \{1, 2, \ldots, n\} + $$ + +## End Result + +If all the checks return `true`, the verifier can determine that the user is valid without knowing the plain `bot_token`. After the setup phase, only Telegram and the bot owner know the plain `bot_token` value, ensuring that no one else can create a valid fake proof. + +## Problems with Our Solution + +Designing the desired $\operatorname{Open}$ function involves dealing with two operations ($+$) and ($\times$) without knowing the underlying message. Currently, we can only do this for the ($+$) operation, making this solution impractical. + +## Conclusion + +Using this strategy does not seem feasible for now. + +## Alternative Solution + +A viable solution is to deploy an intermediate service that receives `user_hash` from users and then returns a new JWT token corresponding to the user's request. The flow would then be the same as the one we have deployed. diff --git a/case_studies/attachments/keyless_account.drawio b/case_studies/attachments/keyless_account.drawio new file mode 100644 index 0000000..cf7e5c5 --- /dev/null +++ b/case_studies/attachments/keyless_account.drawio @@ -0,0 +1,329 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/case_studies/attachments/keyless_account.png b/case_studies/attachments/keyless_account.png new file mode 100644 index 0000000..b1f29a5 Binary files /dev/null and b/case_studies/attachments/keyless_account.png differ diff --git a/case_studies/keyless_account_for_telegram.md b/case_studies/keyless_account_for_telegram.md new file mode 100644 index 0000000..688e813 --- /dev/null +++ b/case_studies/keyless_account_for_telegram.md @@ -0,0 +1,94 @@ +# Keyless Account for Telegram + +!TOC + +## Introduction + +Currently, there is support for users to utilize web3 applications without managing their own public and private key pairs, and without +using custodial wallets, by using their credentials directly from authentication providers like Google or Apple. This is made possible +thanks to zero-knowledge (ZK) technology and account abstraction. However, the current solution +(e.g., [zkLogin](https://docs.sui.io/concepts/cryptography/zklogin)) only supports authentication providers that offer OIDC (OpenID +Connect). Other providers like Telegram cannot be supported using the same technique, so we need to devise an alternative solution. + +In this document, we will analyze and then try to introduce the modified flow that is suited for Telegram. + +> [!NOTE] +> Although we couldn't successfully create a fully working flow. we hope that this will help to bring some info for the interested +> reader. + +## Telegram OAuth Properties + +Telegram uses the HMAC-SHA-256 signature scheme. + +To integrate Telegram authentication, you need to create a bot. Each bot has a unique `bot_token` used by Telegram to create a valid +signature for the user upon successful authorization. More details can be found in +the [Telegram Login Widget](https://core.telegram.org/widgets/login). + +Unlike OIDC, which uses RS256 where only the authentication provider's server can generate a valid signature, HMAC-SHA-256 allows both +the authentication server and the recipient (in this case, our app) to generate valid signatures. + +There is no support for custom fields as opposed to OIDC, which users can use to attach additional information to the authentication +signature. This provides an easy way (as demonstrated in steps (1) and (2) in the OIDC Compatible section of the figure below) to +ensure no one else can create a valid proof and link it with an arbitrary web3 account. + +## The Overview Flow + +![Keyless Account](./attachments/keyless_account.png) + +0. **Bot Token Creation:** The first step (denoted as step 0 in the figure above) is to create a `bot_token` by following the Telegram + instructions. Embed this token (as private) into our circuit so that the circuit can verify the hash without anyone else knowing it. + Since anyone with the bot token can create a valid signature, we need to discard this information (and its hash value) as soon as we + are done generating the circuit. + +1. **User Information Hashing:** When the user logs into Telegram successfully, Telegram will provide us with the `user_info_hash`, + which is derived from the `bot_token` and the `user_info`. + +2. **Ephemeral Key Pair Creation:** The user needs to create an `ephemeral key pair` to interact with the blockchain. Then, hash this + key pair with the received `user_info_hash`, creating `Hash_E`. This information will be put into the circuit to prevent attacks + like frontrunning. Without this step, attackers could attach our proof to any ephemeral account of their choice and still pass all + the checks. Use a zk-friendly hash for efficiency purposes, such as Poseidon. + +3. **Circuit Verification:** In the circuit, use the `user_info` provided by the user and combine it with the + embedded `Hash(bot_token)` value to calculate the `user_info_hash`. This is done in an encrypted context (a feature provided by + using [Homomorphic Commitment](../terms/homomorphic_encryption.md) techniques) so no one can read it. + +4. **Hash Consistency Check:** The newly calculated `user_info_hash` is combined with the `ephemeral public key` provided by the user + to compare with `Hash_E` to ensure consistency. + +5. **Circuit Output:** After verification, the circuit outputs the `ephemeral public key`, the verdict on whether the user input passes + all checks, and the user info. These values can then be used in the smart contract to serve our business logic. The smart contract + can trust that the `ephemeral public key` belongs to a user who has been authenticated by Telegram, allowing for secure interactions + on the blockchain. + +## Appendix + +### HMAC + +This definition is taken from [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104): + +$$ +\begin{align} +\text{HMAC}(K, m) &= \text{H}\Bigl(\bigl(K' \oplus opad\bigr) \parallel +\text{H} \bigl(\left(K' \oplus ipad\right) \parallel m\bigr)\Bigr) \\ +K' &= \begin{cases} +\text{H}\left(K\right) & \text{if K is larger than block size} \\ +K & \text{otherwise} +\end{cases} +\end{align} +$$ + +where: + +- `H` is a cryptographic hash function. +- `m` is the message to be authenticated. +- `K` is the secret key. +- `K'` is a block-sized key derived from the secret key, either by padding to the right with 0s up to the block size, or by hashing + down to less than or equal to the block size first and then padding to the right with zeros. +- $\parallel$ denotes `concatenation`. +- $\oplus$ denotes bitwise `exclusive or` (XOR). +- `opad` is the block-sized outer padding, consisting of repeated bytes valued `0x5c`. +- `ipad` is the block-sized inner padding, consisting of repeated bytes valued `0x36`. + +### HMAC-SHA-256 + +This is basically using HMAC with SHA-256 as the hash function. diff --git a/docs/gsw_fhe_scheme.md b/docs/gsw_fhe_scheme.md index f7e0125..3737108 100644 --- a/docs/gsw_fhe_scheme.md +++ b/docs/gsw_fhe_scheme.md @@ -15,8 +15,8 @@ comments: true ![GSW Encryption Scheme](attachments/gsw_encryption_scheme.png) -- $A$: is the public key; an [LWE matrix](../terms/learning_with_errors.md) (columns are LWE samples): $s^T A = e^T \approx 0^T$ -- $s$: is the secret key. +- $A$: The public key; an [LWE matrix](../terms/learning_with_errors.md) (columns are LWE samples): $s^T A = e^T \approx 0^T$ +- $s$: The secret key. ### Encryption @@ -27,18 +27,17 @@ $$ C = AR + xG $$ -- **[Gadget Matrix](../terms/gadget_matrix.md) $G$**: - [Easy to solve](https://www.jeremykun.com/2021/12/11/the-gadget-decomposition-in-fhe/) $x$ given $G$ and - $s$: +- **[Gadget Matrix](../terms/gadget_matrix.md) $G$**: A matrix that makes it easy to solve $x$ given $G$ and $s$: $$ -G = (1,2,4,\ldots,2^l) \otimes I_n \in \mathbb{Z}_q^{n \times nl} +G = (1, 2, 4, \ldots, 2^l) \otimes I_n \in \mathbb{Z}_q^{n \times nl} $$ -- **Public Trapdoor**: The "binary decomposition," $G^{-1}:\mathbb{Z}_q^{n \times nl} \rightarrow \{0,1\}^{nl \times k}$ - such that +- **Public Trapdoor**: The "binary decomposition," $G^{-1}:\mathbb{Z}_q^{n \times nl} \rightarrow \{0,1\}^{nl \times k}$ such that -$$GG^{-1}(A) = A$$ +$$ +GG^{-1}(A) = A +$$ ### Decryption @@ -86,7 +85,7 @@ $$ ### Correctness -- $R_1$, $R_2$, $x_1$ short ⇒ $R_+$, $R_\times$ also short +- $R_1$, $R_2$, $x_1$ are short, so $R_+$ and $R_\times$ are also short. ### Evaluation @@ -131,10 +130,6 @@ Example: [Lattices, Learning with Errors (page 73)](https://people.csail.mit.edu Where $A$ is actually $C$ and $\mu$ is actually $x$. -#### Applications - -![GSW Applications](attachments/gsw_applications.png) - ## GSW as a Homomorphic Commitment $$ @@ -143,8 +138,8 @@ $$ - View $C$ as the commitment, $x$ as the message, and $R$ as the opening (must be short). -- **Statistically Binding**: Follows from the correctness of GSW (in fact, extractable) -- **Computationally Hiding**: Follows from the security of GSW (under LWE) +- **Statistically Binding**: Follows from the correctness of GSW (in fact, extractable). +- **Computationally Hiding**: Follows from the security of GSW (under LWE). ### Commitment Procedure @@ -171,6 +166,9 @@ $$ The verifier can compute this using the "Input-Independent Evaluation" technique above. +> [!NOTE] +> We can choose $A$ as a uniformly random matrix since we don't need to decrypt the message. + - **Opening**: $$ @@ -182,20 +180,7 @@ $$ - By using this formula, the verifier doesn't need to know any $R_i$. - The prover knows $R_1, \ldots, R_n$. -- $H_{f,x}$ can be computed given the function $f$ and $x$ +- $H_{f,x}$ can be computed given the function $f$ and $x$. - **Check**: - The verifier can then verify $C_f = AR_{f,x} + f(x)G$ as described in the picture above. - -### From Commitments to Non-Interactive Zero-Knowledge - -### Soundness - -[Soundness](../../terms/zkp.md#soundness) - -### Trapdoor - -**Random matrix** $A \times$ **short matrix trapdoor** $R$ = gadget matrix $G$ - -> [!NOTE] -> Given $u = f_A(x)$ and $R$, can sample short $x'$ where $f_A(x')=u$