Security estimate

[Nashtare]

This PR adds proven security level estimate.

Examples now show both conjectured and proven security levels.

The $m$ parameter in the proven security is updated dynamically to optimize the balance between field security and query security. The approach taken is based on the two following assumptions:

• For the "pre-FRI-query err" as mentioned in ethSTARK paper, only the third (dominant) component, i.e. $\dfrac{(m+\frac{1}{2})^7 \cdot n^2}{2\rho^{3/2}q}$, is considered.
• For the "FRI-query err", the value $\sqrt{\rho} \cdot (1 + \frac{1}{2m})$ is approximated by $\sqrt{\rho}$. The reason for this is that the term $\frac{1}{2m} \leq \frac{1}{6}$ is fairly small, and doubling $m$ removes about 7 bits of security for the pre-FRI-query term.

Based on those two assumptions, we can solve (using the paper notations):
$$-\log_2{\dfrac{(m+\frac{1}{2})^7 \cdot n^2}{2\rho^{3/2}q}} = \zeta - s \cdot \log_2{\sqrt{\rho}}$$ which yields

$$\log_2{(m + \frac{1}{2})} = \dfrac{1 + \log_2{q} + \frac{s+3}{2} \log_2{\rho} - \zeta - 2\log_2{n}}{7} = T$$

$$m = 2^T - \frac{1}{2}$$

with

• $\zeta$ the grinding factor
• $\rho$ the inverse of the blowup factor $b$ (i.e. $\log_2{\rho} = -\log_2{b}$)
• $s$ the number of queries
• $q$ the extended field size
• $n$ the extended trace length

[irakliyk]

This looks great! Thank you so much! I left a couple of small comments inline.

One other thing: I haven't cross checked myself yet, but I'm curious how the provable soundness computations here match up with some of the results from this paper (i.e., tables in section 3.5).

[Nashtare]

@irakliyk I've done a few things since your review:

• I removed the commit updating the conjectured security. I feel like we'd need more discussion around whether we want to alter it (through the non-extended trace length, or removing this component completely) before doing any changes.
• I fixed the proven security computation (I'll update the README shortly to detail the approach for computing the closeness parameter $m$ and ease review. Plugging the values from the paper you mentioned, I get ($m$ used in the paper between parenthesis):

For $\lambda$ = 67:

$\log_2 b$	$m$	$\lambda$
3	6.4 (6)	69
4	3.9 (4)	69
5	3.0 (3)	68

For $\lambda$ = 112:
(note here I had to alter the security estimate function manually to test for larger blowup factors)

$\log_2 b$	$m$	$\lambda$
6	21 (16)	115
8	14 (7)	114
10	4.4 (3)	116

For $\lambda$ = 128:

$\log_2 b$	$m$	$\lambda$
3	8.3 (9)	128
4	4.9 (6)	128
5	3.0 (4)	127

[irakliyk]

@Nashtare - thank you! I think we are almost there. The results are pretty close to the expected ones but there are some sets of parameters that give counterintuitive results. For example:

Running fib-small example with -q 38 -b 16 -g 20 -e 2 gives:

Proof security: 118 bits (83 proven)

But if we increase blowup factor to 32 (I had to make a small update to be able to run it) and run with -q 38 -b 16 -g 20 -e 2, we get:

Proof security: 118 bits (79 proven)

Basically, it seems like increasing blowup factor lowers security. I think this happens because for -q 38 -b 32 it doesn't really matter what -g is as we can never get above 79 bits of proven security. But I didn't look deeply enough to understand yet why this has to be the case.

[Nashtare]

This is actually to be expected. To replicate your values, I used fib-small -n 1024 (let me know if you were in a different setting).

For the first case, -q 38 -b 16 -g 20 -e 2 fib-small -n 1024, we obtain the following internal values:

• pre_query_security: 84
• query_security: 67
• query_security + grinding: 87
• m = 3.0

As we can see, both estimates (after grinding adjustement) are fairly close. We can't get better than that, as m is minimal, and increasing it would decrease pre_query_security, decreasing the overall security level.

For the second case, -q 38 -b 32 -g 20 -e 2 fib-small -n 1024, we obtain the following values:

• pre_query_security: 80
• query_security: 86
• query_security + grinding: 106
• m = 3.0

There is now an imbalance between the two levels, which is to be expected. Indeed, the increased LDE domain reduces the estimated security on the first component, while consequently increasing the query security level. When the pre_query_security is the limiting factor, the only thing we can do is reduce the closeness parameter m, down to its minimal value which is already reached here. What could be done, in this scenario, is to decrease the query_security level, without decreasing the overall security level, by going down from 38 to 27 queries. This would yield query_security + grinding: 81.

Note: This situation can also arise with the conjectured security estimate, when field_security becomes the bottleneck with very large traces, and decreasing the overall security level after some threshold. For instance with parameters -q 38 -b 8 -g 20 -e 2, you can compute fib-small with $n = 2^{20}, 2^{22}, 2^{24}$ and notice the conjectured security level going down by 2 bits each time (the bit size increase of the LDE).

[Nashtare]

One thing that I could think of to alleviate this possibly confusing behavior with larger traces/blowup factors, but that would imply quite some refactoring, would be to specify instead a target security level (similarly to what Miden does), along with possibly extra arguments like security_model (conjectured or proven), optimization_level (prover time, proof size), and then compute the required parameters (blowup, nb queries, grinding, ...) based on those. But that's probably not necessary for the examples crate.

[irakliyk]

would be to specify instead a target security level

This would be cool - but I think it could be built on top of the current structure rather than instead of it, and should probably go into a different PR.

the increased LDE domain reduces the estimated security on the first component

Ah - this makes sense now! It is not that the increase in blowup factor by itself leads to lower security, it is that increase in blowup factor leads to increase in LDE domain, and for extension 2 field, this leads to decreased security (and if we are to use extension 3 field, then the the impact would be more "intuitive").

One last comment I have: in the doc comments for get_proven_security - should we say something like "Estimates proven security ..." rather than "Calculates"? If I'm understanding correctly, this code provides a pretty close estimate (i.e., usually with accuracy within 3 bits) but does not always give the exact result - right?

[Nashtare]

If I'm understanding correctly, this code provides a pretty close estimate (i.e., usually with accuracy within 3 bits) but does not always give the exact result - right?

Actually it's slightly different, the code does yield the bit of security claimed by the proven security analysis of the paper.

• for the query security part, we do calculate $\zeta - s \cdot \log_2\left(\sqrt{\rho} \cdot (1 + \frac{1}{2m})\right)$
• for the pre-query security, we only consider the third term inside the log, i.e. $\dfrac{\left(m + \frac{1}{2}\right)^7 \cdot n^2}{2\rho^{3/2}q}$. However, some analysis shows that considering the extra terms will not affect the estimate, by even 1 bit.

The difference with Ulrich's paper comes from the selection of the closeness parameter $m$, which, due to the dynamic update, is in most cases helping to gain 1 to 3 extra bits of security (it was always fixed to 3 for simplicity in the ethSTARK paper).

But it's true that given the way we compute it (with the two light assumptions to derive $m$, "estimate" sounds more accurate). I'll update it.

[irakliyk]

All looks good! Thank you again!