-
Notifications
You must be signed in to change notification settings - Fork 50
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
Add overstretched NTRU estimation functionality #86
Conversation
estimator/ntru_primal.py
Outdated
class NTRUPrimalUSVP(PrimalUSVP): | ||
|
||
@staticmethod | ||
def _solve_for_d(params, m, beta, tau, xi): |
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.
Is this copied from LWE? Can we reuse the code instead?
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.
Yes. But it is overloaded to account for the fact that NTRU is homogeneous. References to tau were deleted.
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.
Shall we make that a parameter?
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.
I think we could stick with the convention that tau=None means that the instance is homogeneous, but then we'd need to control how to set Tau to None. This could be done through an additional attribute in LWEParameters.
estimator/ntru_primal.py
Outdated
|
||
@staticmethod | ||
@cached_function | ||
def cost_gsa( |
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.
Can we re-use existing code?
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.
Unfortunately, no. Needed to remove references to Tau to account for the fact that NTRU is homogeneous.
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.
We could generalise the underlying code, though? At least this function shouldn't take tau or throw an error when tau is provided?
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.
It's an overload, so convention dictates it has the same method signature. All of these cost functions set Tau automatically if Tau is None. But in simulator.py Tau=None is the convention for homogeneous systems. I wanted to take the route of adding new code, rather than modifying existing code. I can certainly generalize these functions.
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.
I'd say this isn't C++ :) I'd say "tau=None" is "choose automatically" and "tau=False" is "homogeneous"? Would that make sense?
estimator/simulator.py
Outdated
:param xi: Scaling factor ξ for identity part. | ||
:param dual: ignored, since GSA is self-dual: applying the GSA to the dual is equivalent to | ||
applying it to the primal. | ||
:returns: Log Gram-Schmidt norms |
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.
Would be good to have a doctest as an example on how to call this
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.
Happy to add, but none of the other Simulator functions have doctests.
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.
Yeah, let's improve the code base … good ol' scope creep :)
estimator/util.py
Outdated
@@ -4,16 +4,46 @@ | |||
from dataclasses import dataclass | |||
from typing import Any, Callable, NamedTuple | |||
|
|||
from sage.all import ceil, floor, log, oo | |||
from sage.all import ceil, floor, log, oo, cached_function | |||
from scipy.special import zeta |
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.
Why scipy and not Sage?
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.
scipy zeta function returns +inf on zeta(1), sage zeta function returns an unsigned Infinity, which can't be converted to RR.
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.
Still, I think we should use Sage's functions, it reads easier?
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.
It definitely does. But it straight up breaks everything. I can't reassign unsigned Infinity to +infinity (oo), they're derived from two completely different objects (Signed Infinity Ring v.s. Unsigned Infinity Ring).
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.
It's impossible to cast unsigned infinity to anything useful. I could create a lambda that specifically returns +infinity at 1, but zeta(x) everywhere else, though I'd argue that's equally messy.
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.
Kay, let's leave it as is but document why?
…eneous Doctests were changed in accordance with the updated homogeneity checks. Previously, the +1 on line 261 of lwe_primal.py was removed, with the assumption that a homogeneous instance would not need the additional dimension. This was a mistake, and improperly gimping the dimension optimization functionality for homogeneous instances. This commit rectifies this mistake by updating the doctests to be in line with the more efficient implementation.
Resolves #26
Adds a new, separate API for NTRU estimation specifically, alongside a new NTRUParameters data class. NTRU only supports primal attacks, so only an ntru_primal attack file is included. Outputs for the new
primal_dsd
attack match those from estimates generated from https://github.com/WvanWoerden/NTRUFatigue