Passing non-positive-integer secparam in PairingGroup construction #312
Comments
BatchClayderman
added a commit
to BatchClayderman/charm
that referenced
this issue
Feb 1, 2025
Issue JHUISI#313 - Fix the multiple GT element generation issue. - Modify the original recursive logic to a simpler ``if-else`` logic. - Pre-generate the ``__gt`` when the object is instantiated, without having to check whether ``__gt`` has been generated every time a random GT element is required to be generated. - No seeds will be passed to the imported ``random`` function to generate different random elements when multiple elements are required to be generated even though a seed is specified to call the ``random`` method of the ``PairingGroup`` class. Issue JHUISI#312 - Optimize the ``/ 8`` to ``>> 3``.
BatchClayderman
added a commit
to BatchClayderman/charm
that referenced
this issue
Feb 1, 2025
Issue JHUISI#313 - Fix the multiple GT element generation issue. - Modify the original recursive logic to a simpler ``if-else`` logic. - Pre-generate the ``__gt`` when the object is instantiated, without having to check whether ``__gt`` has been generated every time a random GT element is required to be generated. - No seeds will be passed to the imported ``random`` function to generate different random elements when multiple elements are required to be generated even though a seed is specified to call the ``random`` method of the ``PairingGroup`` class. Issue JHUISI#312 - Optimize the ``/ 8`` to ``>> 3``.
jakinyele
pushed a commit
that referenced
this issue
Feb 3, 2025
Issue #313 - Fix the multiple GT element generation issue. - Modify the original recursive logic to a simpler ``if-else`` logic. - Pre-generate the ``__gt`` when the object is instantiated, without having to check whether ``__gt`` has been generated every time a random GT element is required to be generated. - No seeds will be passed to the imported ``random`` function to generate different random elements when multiple elements are required to be generated even though a seed is specified to call the ``random`` method of the ``PairingGroup`` class. Issue #312 - Optimize the ``/ 8`` to ``>> 3``.
jakinyele
pushed a commit
that referenced
this issue
Feb 3, 2025
Issue #313 - Fix the multiple GT element generation issue. - Modify the original recursive logic to a simpler ``if-else`` logic. - Pre-generate the ``__gt`` when the object is instantiated, without having to check whether ``__gt`` has been generated every time a random GT element is required to be generated. - No seeds will be passed to the imported ``random`` function to generate different random elements when multiple elements are required to be generated even though a seed is specified to call the ``random`` method of the ``PairingGroup`` class. Issue #312 - Optimize the ``/ 8`` to ``>> 3``.
|
Fixed in the merged PR - #313 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, guys.$\lambda$ ) can decide the security level of a system in theory.
Recently, I have been confused about the
secparamin the classPairingGroup.I knew that the security parameter (
However, when I passed different values like
-1,0.5,7,512, and1024to create aPairingGroupobject, I found there seemed to be no differences in time or communication costs in cryptography schemes.Moreover, I have searched the
secparamin codes related toPairingGroupand only foundmessageSizeinvolves the variablesecparam.Thus, I am confused about the role the Python parameter
secparamplays in the class PairingGroup and whether it makes sense to pass values like-1,0.5, and7both in theoretical cryptography schemes and practical Python charm library-related implementations.By the way, if the
secparamis limited to positive integers in__init__, it may be better to use>> 3instead of/ 8inmessageSize.Thanks & regards.
The text was updated successfully, but these errors were encountered: