Skip to content

Commit

Permalink
removing typo
Browse files Browse the repository at this point in the history
  • Loading branch information
madhavanmalolan committed Jun 14, 2024
1 parent 5e14561 commit 237e37c
Show file tree
Hide file tree
Showing 2 changed files with 107 additions and 25 deletions.
69 changes: 50 additions & 19 deletions content/posts/proxying-is-enough.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -68,36 +68,67 @@ Plugging in the values for AES,

[That gives us](https://www.wolframalpha.com/input?i=log_10%28%2863*3600%29%5E2%2F%282%5E%288*56+-+2*128+%2B2%29%29%29) the probaility of the proof having been fradulently created to be

$0.0000000000000000000000000000000000000000000001$ %
$0.0000000000000000000000000000000000000000000001\\%$

That is an extremely small probability, and secure enough to practically say that we can be certain that the proof generated is fully secure.
That is an extremely small probability, and secure enough to practically say that we can be certain that the proof generated is fully secure. To put it in perspective, this probability is so low that, if all the computers, including your mobile phone, in the world were dedicated breaking the security of this protocol - it would take _ten million times the age of the universe_ to actually break it!

## Using ChaCha20 looks ...
AESGCM is the most popular, but it isn't zk friendly. Writing zk circuits for AESGCM can be very inefficient. So, Reclaim Protocol uses ChaCha20 instead. ChaCha20 is the second most popular cryptographic algorithm in HTTPS. [99%](https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report) of all the websites support ChaCha20. It is a requirement for every website to support ChaCha20 in TLS1.3 onwards.
## The Real Numbers, in production
Ok, so that works for the values that have been used by the paper. Let's see what values apply for Reclaim in practice.

Ok, so let's plug in those numbers
- $|S| = 63 * 3600$ ; stays the same
- $\lambda = 56*8$ ; stays the same
- $l=512$ ; block size for ChaCha20 is 512 bits
Reclaim Protocol supports both AES-GCM and ChaCha20. However, in production we prefer ChaCha20. That is because of the number of constraints in the circuit, which implies performance on consumer grade devices.

[That gives us](https://www.wolframalpha.com/input?i=log_10%28%2863*3600%29%5E2%2F%282%5E%288*56+-+2*512+%2B2%29%29%29) ... something wrong.
![ChaCha Formula](/images/zluo-6.1_corrected.png)

The formula tells us that the probability that the proof you are looking at is $10^{185}$% a fraud. That doesn't make sense.
1. Probability can't be greater than 100%, leave alone 1 followed by 185 zeros percent.
2. This means, if you use ChaCha20, you can be (beyond) certain that the user has cheated, even when we know that the user is honest. That doesn't feel natural, does it?
### Padding, $\lambda$
The paper recommends revealing the first two lines of the header in the response - the http status code and date.
In our implementation, we reveal the following
1. HTTP Status code
2. Connection header
3. URL

## We reached out to Z Luo
When running our numbers on our actual production parameters, we realized there seems to be an issue - as we saw above. We reached out to Z Luo, who was very receptive and offered to dive deeper.
This is very specific to our implementation. On Reclaim Protocol, we have the users commit to the "provider" they are generating a proof for. So, they commit to the URL before executing the HTTPS Handshake. The protocol described in the paper is more generic. That is the user can prove something about any arbitrary HTTPS request they make from their browser, making the URL an unknown. If we get rid of that generalization, the known URL header can be used as _padding_.

![zluo discord](/images/zluo-discord.png)
Another small modification from the paper is that instead of revealing the first few characters as padding, we mix and match various parts of the headers to form a long enough invariant. We identify various parts of the headers that we know the values of before hand. This is possible because of the product/protocol specific assumptions made, which constrains the things a malicious user can modify in the headers.

## The updated formula
Coming soon ...
- Shortest status code : `http/1.1 200 OK` ; 15 characters
- Connection header : `connection: close` ; 17 characters
- Shortest possible URL : `https://a.co` ; 12 characters

## The Real Numbers, in production
Coming soon ...
So, we're looking at a minimum of 44 characters being used as padding.
$$\lambda = 44 \text{bytes} = 352 \text{bits}$$

### Number of valid openings, $|S|$
|S| represents size of the set of all the values that the padding can map to.

**Http Status Code**
- HTTP version : only accepted value is `1.1`, which is the most supported version. Versions `2` and `3` are backward compatible with `1.1`
- Status code : only accepted value is `200`, which is the status code for everything is OK and response is contained in the body

**Connection header**
- Every https connection is expected to have a `connection close` header. there are no variations for this header. So, there is exactly one valid opening for this header.

**URL**
- The url is known before hand, so there is exactly one valid opening for the URL

So, total valid openings is exactly $1$.
$$ |S| = 1 $$

### Key size
Since we use chacha20, the keysize is 256 bits
$$|k| = 256 $$

### Putting everything together
Feeding the above values in the formula, [we get probability](https://wolframalpha.com/https://www.wolframalpha.com/input?i=log_10%281%2F2%5E%2860*8+-+2*96+%2B1%29%29) of breaking the security of Reclaim Protocol as
$$ 10^-85 \text{\\%}$$

Again, that means if all the computers on the planet including everything from your mobile phone to all the A100 gpus used for LLM training, you would need $10^45$ times the age of the universe to break the security.

Not bad. At all.

# Conclusion
The Proxying method used by Reclaim Protocol is secure for practical use, beyond any doubt -- putting an end to the debate whether or not proxying is secure enough when compared to the MPC based approaches for zk-tls.

This is not to shit on the work being done by the teams on the MPC approach. That is valuable, and Reclaim Protocol continues to explore the frontiers of what is possible and what is more efficient - in close collaboration with teams working on alternate approaches. ZK is fast evolving. Staying on the bleeding edge is extremely critical.

That said, it turns out **_Proxying is enough_** to take the solution to market.

63 changes: 57 additions & 6 deletions public/posts/proxying-is-enough/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -181,8 +181,8 @@ <h2 id="using-aes-gcm-looks-very-secure">Using AES-GCM looks very secure<a hidde
<li>$l=128$ ; block size for AESGCM is 128 bits</li>
</ul>
<p><a href="https://www.wolframalpha.com/input?i=log_10%28%2863*3600%29%5E2%2F%282%5E%288*56+-+2*128+%2B2%29%29%29">That gives us</a> the probaility of the proof having been fradulently created to be</p>
<p>$0.0000000000000000000000000000000000000000000001$ %</p>
<p>That is an extremely small probability, and secure enough to practically say that we can be certain that the proof generated is fully secure.</p>
<p>$0.0000000000000000000000000000000000000000000001\%$</p>
<p>That is an extremely small probability, and secure enough to practically say that we can be certain that the proof generated is fully secure. To put it in perspective, this probability is so low that, if all the computers, including your mobile phone, in the world were dedicated breaking the security of this protocol - it would take <em>ten million times the age of the universe</em> to actually break it!</p>
<h2 id="using-chacha20-looks-">Using ChaCha20 looks &hellip;<a hidden class="anchor" aria-hidden="true" href="#using-chacha20-looks-">#</a></h2>
<p>AESGCM is the most popular, but it isn&rsquo;t zk friendly. Writing zk circuits for AESGCM can be very inefficient. So, Reclaim Protocol uses ChaCha20 instead. ChaCha20 is the second most popular cryptographic algorithm in HTTPS. <a href="https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report">99%</a> of all the websites support ChaCha20. It is a requirement for every website to support ChaCha20 in TLS1.3 onwards.</p>
<p>Ok, so let&rsquo;s plug in those numbers</p>
Expand All @@ -192,19 +192,70 @@ <h2 id="using-chacha20-looks-">Using ChaCha20 looks &hellip;<a hidden class="anc
<li>$l=512$ ; block size for ChaCha20 is 512 bits</li>
</ul>
<p><a href="https://www.wolframalpha.com/input?i=log_10%28%2863*3600%29%5E2%2F%282%5E%288*56+-+2*512+%2B2%29%29%29">That gives us</a> &hellip; something wrong.</p>
<p>The formula tells us that the probability that the proof you are looking at is $10^{185}$% a fraud. That doesn&rsquo;t make sense.</p>
<p>The formula tells us that the probability that the proof you are looking at is $10^{185}\%$ a fraud. That doesn&rsquo;t make sense.</p>
<ol>
<li>Probability can&rsquo;t be greater than 100%, leave alone 1 followed by 185 zeros percent.</li>
<li>This means, if you use ChaCha20, you can be (beyond) certain that the user has cheated, even when we know that the user is honest. That doesn&rsquo;t feel natural, does it?</li>
<li>This means, if you use ChaCha20, you can be (beyond) certain that the user has cheated, even when we know that the user is honest. That doesn&rsquo;t feel natural, does it? Even if you know that you are not cheating, and execute the protocol &ndash; it is <em>certain</em> that the output will suggest that you are cheating.</li>
</ol>
<h2 id="we-reached-out-to-z-luo">We reached out to Z Luo<a hidden class="anchor" aria-hidden="true" href="#we-reached-out-to-z-luo">#</a></h2>
<p>When running our numbers on our actual production parameters, we realized there seems to be an issue - as we saw above. We reached out to Z Luo, who was very receptive and offered to dive deeper.</p>
<p><img loading="lazy" src="/images/zluo-discord.png" alt="zluo discord" />
</p>
<h2 id="the-updated-formula">The updated formula<a hidden class="anchor" aria-hidden="true" href="#the-updated-formula">#</a></h2>
<p>Coming soon &hellip;</p>
<p>Very quickly, Z Luo identified and fixed the error. This was the <a href="https://zhtluo.com/paper/Proxying_is_Enough__Security_of_Proxying_in_TLS_Oracles_and_AEAD_Context_Unforgeability.pdf">updated paper</a> and its <a href="https://etherscan.io/tx/0x437fd4f34e41ddea9805b914166bf19aa75daa5066c4ec90528565718171bf52">hash</a></p>
<p>We are extremely thankful to Z Luo for a quick turn around time on this. A sign of true master, when one is able to identify and fix issues almost on the fly!</p>
<p>The updated formula is
<img loading="lazy" src="/images/zluo-6.1_corrected.png" alt="zluo 6.1 updated" />
</p>
<p><em>We feel confident this theorem is now accurate.</em></p>
<h2 id="the-real-numbers-in-production">The Real Numbers, in production<a hidden class="anchor" aria-hidden="true" href="#the-real-numbers-in-production">#</a></h2>
<p>Coming soon &hellip;</p>
<p>Ok, so that works for the values that have been used by the paper. Let&rsquo;s see what values apply for Reclaim in practice.</p>
<h3 id="padding-lambda">Padding, $\lambda$<a hidden class="anchor" aria-hidden="true" href="#padding-lambda">#</a></h3>
<p>The paper recommends revealing the first two lines of the header in the response - the http status code and date.
In our implementation, we reveal the following</p>
<ol>
<li>HTTP Status code</li>
<li>Connection header</li>
<li>URL</li>
</ol>
<p>This is very specific to our implementation. On Reclaim Protocol, we have the users commit to the &ldquo;provider&rdquo; they are generating a proof for. So, they commit to the URL before executing the HTTPS Handshake. The protocol described in the paper is more generic. That is the user can prove something about any arbitrary HTTPS request they make from their browser, making the URL an unknown. If we get rid of that generalization, the known URL header can be used as <em>padding</em>.</p>
<p>Another small modification from the paper is that instead of revealing the first few characters as padding, we mix and match various parts of the headers to form a long enough invariant. We identify various parts of the headers that we know the values of before hand. This is possible because of the product/protocol specific assumptions made, which constrains the things a malicious user can modify in the headers.</p>
<ul>
<li>Shortest status code : <code>http/1.1 200 OK</code> ; 15 characters</li>
<li>Connection header : <code>connection: close</code> ; 17 characters</li>
<li>Shortest possible URL : <code>https://a.co</code> ; 12 characters</li>
</ul>
<p>So, we&rsquo;re looking at a minimum of 44 characters being used as padding.
$$\lambda = 44 \text{bytes} = 352 \text{bits}$$</p>
<h3 id="number-of-valid-openings-s">Number of valid openings, $|S|$<a hidden class="anchor" aria-hidden="true" href="#number-of-valid-openings-s">#</a></h3>
<p>|S| represents size of the set of all the values that the padding can map to.</p>
<p><strong>Http Status Code</strong></p>
<ul>
<li>HTTP version : only accepted value is <code>1.1</code>, which is the most supported version. Versions <code>2</code> and <code>3</code> are backward compatible with <code>1.1</code></li>
<li>Status code : only accepted value is <code>200</code>, which is the status code for everything is OK and response is contained in the body</li>
</ul>
<p><strong>Connection header</strong></p>
<ul>
<li>Every https connection is expected to have a <code>connection close</code> header. there are no variations for this header. So, there is exactly one valid opening for this header.</li>
</ul>
<p><strong>URL</strong></p>
<ul>
<li>The url is known before hand, so there is exactly one valid opening for the URL</li>
</ul>
<p>So, total valid openings is exactly $1$.
$$ |S| = 1 $$</p>
<h3 id="key-size">Key size<a hidden class="anchor" aria-hidden="true" href="#key-size">#</a></h3>
<p>Since we use chacha20, the keysize is 256 bits
$$|k| = 256 $$</p>
<h3 id="putting-everything-together">Putting everything together<a hidden class="anchor" aria-hidden="true" href="#putting-everything-together">#</a></h3>
<p>Feeding the above values in the formula, <a href="https://wolframalpha.com/https://www.wolframalpha.com/input?i=log_10%281%2F2%5E%2860*8+-+2*96+%2B1%29%29">we get probability</a> of breaking the security of Reclaim Protocol as
$$ 10^-85 \text{\%}$$</p>
<p>Again, that means if all the computers on the planet including everything from your mobile phone to all the A100 gpus used for LLM training, you would need $10^45$ times the age of the universe to break the security.</p>
<p>Not bad. At all.</p>
<h1 id="conclusion">Conclusion<a hidden class="anchor" aria-hidden="true" href="#conclusion">#</a></h1>
<p>The Proxying method used by Reclaim Protocol is secure for practical use, beyond any doubt &ndash; putting an end to the debate whether or not proxying is secure enough when compared to the MPC based approaches for zk-tls.</p>
<p>This is not to shit on the work being done by the teams on the MPC approach. That is valuable, and Reclaim Protocol continues to explore the frontiers of what is possible and what is more efficient - in close collaboration with teams working on alternate approaches. ZK is fast evolving. Staying on the bleeding edge is extremely critical.</p>
<p>That said, it turns out <strong><em>Proxying is enough</em></strong> to take the solution to market.</p>


</div>
Expand Down

0 comments on commit 237e37c

Please sign in to comment.