Optimize the Previous Pull Request #314 for further processing Issue #312#325
Optimize the Previous Pull Request #314 for further processing Issue #312#325yueryang wants to merge 13 commits intoJHUISI:devfrom yueryang:dev
Conversation
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``.
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``.
There was a problem hiding this comment.
Thank you for your contribution, @BatchClayderman! I am ok with these improvements to messageSize. Perhaps it might be good to include your rationale as a comment directly in pairinggroup.py.
Also, it appears there are conflicts that need to be resolved manually. Can you pls fix and then resubmit the PR?
|
Thank you for your prompt reply. I have made my modifications based on the latest CI (#328 ) and included my comments near my modifications. I have also fixed those issues. Hope these small contributions can make the Python charm library better. |
|
Looks like this PR can't be rebased/merged. Not sure what the issue is yet. Will investigate later. Or let me know if you figure it out. Thanks |
|
@BatchClayderman Might need to create a new PR based on the latest commit. Not sure why i can't merge. |



During the construction of the
PairingGroup:secparampassed is valid.For the method
messageSizethat computes the size of a message:ceiland/.return self.secparam >> 3toreturn (self.secparam + 1) >> 3Additionally, it is also OK to only accept$\lambda$ that meets $8 | \lambda$ , from my perspective. After importing
ceilfrommathand making theceila local variable,ceil(self.secparam / 8)can faster than(self.secparam + 1) >> 3only when the computation is used multiple times within the function. For example,is faster than
. However, in this situation, the computation of the message size is only used once in the method
messageSize. Thus, we prefer to usereturn (self.secparam + 1) >> 3, which is faster thanreturn ceil(self.secparam / 8).Thank you for your consideration of this pull request to enhance the previous PR #314.