SOT-168: Keyless account for telegram

Untitled 2.md

@@ -0,0 +1,107 @@
+### 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:
+
+- $\operatorname{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.
+
+## The Solution
+
+### Setup Phase (performed by a trusted party):
+
+1. **Generate FHE Key Pair:**
+   $$(ck, sk) = Keypair()$$
+   where:
+    - $ck$ is the client key used to encrypt values and cannot be used to decrypt.
+    - $sk$ is the server key used to perform homomorphic operations.
+    - $Keypair()$ is the function that generates $ck$ and $sk$.
+
+2. **Encrypt the `bot_token`:**
+   $$bot\_token\_e = Enc(ck, bot\_token)$$
+   where:
+    - $bot\_token\_e$ is the encrypted `bot_token` value using FHE.
+	- $\text{bot\_token}$ is generated by Telegram when creating a new application.
+    - $Enc$ is the FHE encryption function.
+
+3. **Make `bot_token_e`, `ck`, and `sk` public.**
+
+### Proving Phase
+
+After successful authentication, Telegram provides the user with:
+$$user\_info \text{ and } user\_hash = Hmac(bot\_token, user\_info)$$
+where:
+
+- $\text{Hmac}$ is the HMAC algorithm.
+- $\text{user\_info}$ contains the Telegram user's info, including _id_, _first_name_, _last_name_, _username_, _photo_url_, and
+  _auth_date_ fields.
+
+The user then encrypts:
+$$user\_hash\_e = Enc(ck, user\_hash)$$
+and
+$$user\_info\_e = Enc(ck, user\_info)$$
+where:
+
+- $user\_hash\_e$ is the encrypted `user_hash` value using FHE.
+- $user\_info\_e$ is the encrypted `user_info` value using FHE.
+
+These values are then sent to the verifier (i.e., our smart contract).
+
+### Verification Phase
+
+The verifier computes:
+$$user\_hash\_e\_computed = Hmac\_e(sk, bot\_token\_e, user\_info\_e)$$
+where:
+
+- $user\_hash\_e\_computed$ is the encrypted `user_hash` value computed by the verifier.
+- $Hmac\_e$ is the HMAC equivalent function on FHE.
+
+The verifier then performs the check:
+$$Equal\_e(sk, user\_hash\_e\_computed, user\_hash\_e) \stackrel{?}{=} true$$
+where:
+
+- $Equal\_e$ is the equivalence check function on FHE that determines whether two encrypted values are the same.
+
+### End Result
+
+If the result is true, the verifier can determine that the user is valid without knowing the plain user info or the plain hash value.
+After the setup phase, only Telegram and the bot owner know the plain `bot_token` value, ensuring that no one can create a valid fake
+proof.
+
+### Problems with Our Solution
+
+1. So far, we haven't found an appropriate FHE algorithm that uses a one-way key pair, meaning we couldn't find a $ck$ that only
+   performs encryption and not decryption.
+2. Since the underlying implementation of HMAC uses SHA-256, which processes the input bit-by-bit, implementing the $Hmac\_e$ requires
+   working with bit-by-bit encrypted values. This poses a problem:
+    - If the encryption is deterministic (e.g., if bit 1 always encrypts to $x$ and bit 0 always encrypts to $y$), then because we
+      publicize the values, an attacker can easily guess the original value from the encrypted ones.
+    - If the encryption is non-deterministic, implementing the compare function within the FHE seems impossible.
+
+### 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.