Skip to content
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 support for Ristretto255 #646

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

joernheissler
Copy link

This adds support for https://doc.libsodium.org/advanced/point-arithmetic/ristretto / https://ristretto.group/
I'll finish the docstrings and add documentation once the public interface is stable.

Base automatically changed from master to main February 13, 2021 18:38
@reaperhulk
Copy link
Member

We need some docs for the ristretto class, but this approach generally looks correct.

@reaperhulk
Copy link
Member

Just a ping to see if there's a desire to finish the docs here so we can merge.

@joernheissler
Copy link
Author

There is and it's on my ToDo short list :-)
Hopefully some time next Week!

@reaperhulk
Copy link
Member

I'd like to have this feature land in PyNaCl 1.5.0 so I'm holding that release a bit hoping we can get this in there first 😄

@reaperhulk
Copy link
Member

(Ping)

@joernheissler
Copy link
Author

Pong!
(Really sorry for yet another huge delay)

@joernheissler
Copy link
Author

@joernheissler joernheissler marked this pull request as ready for review December 28, 2021 22:00
Copy link
Member

@reaperhulk reaperhulk left a comment

Choose a reason for hiding this comment

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

A few small comments and one big one: Why does Ristretto255Scalar allow native Python types to do scalar math in the field? From my perspective that seems to have very little advantage in exchange for a lot of dangerous complexity. Do you have a specific use case that makes this desirable?

return ffi.buffer(z, crypto_core_ristretto255_SCALAR_BYTES)[:]


if has_crypto_core_ristretto25519:
Copy link
Member

Choose a reason for hiding this comment

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

Why not put this up with the other check?

crypto_core_ristretto255_SCALAR_BYTES = 0
crypto_core_ristretto255_NONREDUCED_SCALAR_BYTES = 0

if has_crypto_core_ristretto25519: # pragma: no branch
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't need a pragma since we do coverage on both minimal and non-minimal builds, did you see a coverage issue?

Copy link
Author

Choose a reason for hiding this comment

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

When I run tox, minimal build isn't checked. How should I run tox to check both?

src/nacl/bindings/crypto_core_ristretto255.py Show resolved Hide resolved
@joernheissler
Copy link
Author

Why does Ristretto255Scalar allow native Python types to do scalar math in the field? From my perspective that seems to have very little advantage in exchange for a lot of dangerous complexity. Do you have a specific use case that makes this desirable?

I feel that it's actually useful. But looking at the examples that I already wrote, somehow I don't use it.
Only place I actually did use Fractions and ints is with scalar multiplication on points.
I'll remove that convenience feature in the scalar field and explicitly allow int+Fraction in Points.

@reaperhulk
Copy link
Member

I'm pretty negative on allowing other Python types to interact via infix operators with points (or scalars) absent a compelling counterargument. Why not just have users create additional points and use those points to perform mathematical operations?

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

Successfully merging this pull request may close these issues.

2 participants