-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security estimate #151
Security estimate #151
Conversation
548b1e4
to
f7b8f8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
f7b8f8f
to
6711630
Compare
ed8741f
to
9310103
Compare
@irakliyk I've done a few things since your review:
For
For
For
|
633d38d
to
c168e59
Compare
@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
But if we increase blowup factor to 32 (I had to make a small update to be able to run it) and run with
Basically, it seems like increasing blowup factor lowers security. I think this happens because for |
This is actually to be expected. To replicate your values, I used For the first case,
As we can see, both estimates (after grinding adjustement) are fairly close. We can't get better than that, as For the second case,
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 Note: This situation can also arise with the conjectured security estimate, when |
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 |
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.
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 |
Actually it's slightly different, the code does yield the bit of security claimed by the proven security analysis of the paper.
The difference with Ulrich's paper comes from the selection of the closeness parameter But it's true that given the way we compute it (with the two light assumptions to derive |
d27d173
to
6dbadd6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good! Thank you again!
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:
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
with