Unable to compute inverse of a scalar while using the Oblivious.ristretto library

[rashmibhle]

When I try to find an inverse of a scalar, it doesn't work as expected while using the Oblivious.ristretto library.

I tried couple of variations to test out the discrepancy in the behavior.

Here are few of those instances:

#Some scalar s
s = scalar.hash("s".encode())

The scalars for which I am able to get an inverse:
~(s)
~(s * s)

But, if the scalar is of the form (s + s'), I am not able to get the inverse of it.
It throws - TypeError: bad operand type for unary ~: 'bytes'. I also tried using the inverse() method but that failed to work too.

Surprisingly, this error seems to be localised only within the Oblivious.ristretto library. The Oblivious.bn254 works well and behaves as expected.

We tested out these instances on google colab. Adding python code here for reference.

from oblivious.ristretto import point, scalar

s = scalar.hash(b"123")
m =  scalar.hash(b"456")

#Works
~(s)
~(s*s)

#Doesn't work
~(s+s)
~(s+m)

Do let me know if you need more context.

[wyatt-howe]

Hi! Thanks for using oblivious!

Good catch. There is not a glitch in the type casting of the scalar that the overloaded scalar + scalar addition method returns, because there isn't such a method to begin with, in Ristretto255. Specifically, oblivious.bn254 supports operating over the full ring of scalars, that is, both additive and multiplicative group operations, while oblivious.ristretto only supports the multiplicative ones.

More clearly, oblivious.ristretto.scalar objects can only be multiplied and inverted (s * s or ~s as you've seen), and doing s + s returns a byte string of length 64 (double the length of a 32-byte, 255-bit scalar) from the byte string concatenation.

It's a good catch because, implicitly casting to bytes and concatenation is not the expected behavior by any means. In the next version, we will either have evaluating the expression s + s raise an exception saying "+ is not implemented yet" or simply implement/bring all of BN254's nice scalar arithmetic that is currently lacking from Ristretto255 into oblivious.ristretto for your use.

[wyatt-howe]

TL;DR:

Addition of Ristretto255 scalars is not supported

type(s) is oblivious.ristretto.scalar
s + s  # bytes

The above expression actually unexpectedly yeilds a 64-byte-long bytes object which is the concatenation of s, casted to bytes(s), with itself.

Negation of Ristretto255 scalars is also not supported

type(s) is oblivious.ristretto.scalar
-s  # error

[wyatt-howe]

Moved to #9. Thanks @rashmibhle for raising this discrepancy to our attention.

[rashmibhle]

Hi Wyatt, Thanks for looking into this issue for me. I am happy to know that this edge case will be handled gracefully moving forward. Hope to see the next version soon! Regards, Rashmi Raghu

…

On Fri, May 3, 2024 at 1:16 PM Wyatt Howe ***@***.***> wrote: Hi! Thanks for using oblivious! Good catch. There is not a glitch in the type casting of the scalar that the overloaded scalar + scalar addition method returns, because there isn't such a method to begin with, in Ristretto255. Specifically, oblivious.bn254 supports operating over the full ring of scalars, that is, both additive and multiplicative group operations, while oblivious.ristretto only supports the multiplicative ones. More clearly, oblivious.ristretto.scalar objects can only be multiplied and inverted (s * s or ~s as you've seen), and doing s + s returns a byte string of length 64 (double the length of a 32-byte, 255-bit scalar) from the byte string concatenation. It's a good catch because, implicitly casting to bytes and concatenation is not the expected behavior by any means. In the next version, we will either have evaluating the expression s + s raise an exception saying "+ is not implemented yet" or simply implement/bring all of BN254's nice scalar arithmetic that is currently lacking from Ristretto255 into oblivious.ristretto for your use. — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALM4BQMM6PAO3OV52O4TWC3ZAPWBJAVCNFSM6AAAAABHEUR7SCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTG4YDEMBWG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>