Skip to content

Optimize the Previous Pull Request #314 for further processing Issue #312#325

Closed
yueryang wants to merge 13 commits intoJHUISI:devfrom
yueryang:dev
Closed

Optimize the Previous Pull Request #314 for further processing Issue #312#325
yueryang wants to merge 13 commits intoJHUISI:devfrom
yueryang:dev

Conversation

@yueryang
Copy link
Copy Markdown
Contributor

During the construction of the PairingGroup:

  • Check whether the secparam passed is valid.

For the method messageSize that computes the size of a message:

  • Given that:
    • All the security parameters are positive integers (limited by the modification above);
    • Byte alignment is required, that is, after filling several bytes, any remaining one or more bits will occupy an additional byte, even if they do not form a complete byte;
    • $1, 2, \cdots, 8$ bit(s) occurpy $1$ byte, $9, 10, \cdots, 16$ bits occurpy $2$ bytes, $\cdots$; and
    • Issue Passing non-positive-integer secparam in PairingGroup construction #312 suggested bitwise operations, which is faster than ceil and /.
  • We modify return self.secparam >> 3 to return (self.secparam + 1) >> 3

Additionally, it is also OK to only accept $\lambda$ that meets $8 | \lambda$, from my perspective. After importing ceil from math and making the ceil a local variable, ceil(self.secparam / 8) can faster than (self.secparam + 1) >> 3 only when the computation is used multiple times within the function. For example,

from math import ceil

def func():
    c = ceil
    for i in range(100000000):
        c(i / 8)

is faster than

def func():
    for i in range(100000000):
        (i + 7) >> 3

. However, in this situation, the computation of the message size is only used once in the method messageSize. Thus, we prefer to use return (self.secparam + 1) >> 3, which is faster than return ceil(self.secparam / 8).

Thank you for your consideration of this pull request to enhance the previous PR #314.

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``.
@jakinyele jakinyele self-requested a review June 19, 2025 04:59
Copy link
Copy Markdown
Member

@jakinyele jakinyele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@yueryang
Copy link
Copy Markdown
Contributor Author

yueryang commented Jun 19, 2025

Thank you for your prompt reply. I have made my modifications based on the latest CI (#328 ) and included my comments near my modifications.
By the way, after the make test run in your Actions tab and on my local machine, I found an error and some warnings caused by the escape characters in the comments from other Python scripts.

image
image

I have also fixed those issues. Hope these small contributions can make the Python charm library better.

@jakinyele
Copy link
Copy Markdown
Member

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

@yueryang
Copy link
Copy Markdown
Contributor Author

Sorry for the inconvenience caused. It seemed normal here from my view.

image

@jakinyele
Copy link
Copy Markdown
Member

jakinyele commented Jun 20, 2025

@BatchClayderman Might need to create a new PR based on the latest commit. Not sure why i can't merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants