As a developer I want to know if dalek rust can support EC math for range proofs

[franssl]

All the ec operations we would need for pederson and rangeproof are in the dalek library.

[franssl]

Leaving this open for James to consider any implications of FFI section of readme https://github.com/dalek-cryptography/curve25519-dalek

[nshCore]

@franssl is this applicable to the ed25519 curve we are using as well -> https://github.com/dalek-cryptography/ed25519-dalek?

Again this is not my area of expertise, my interpretation of this is to not call this library directly, but it should be used from a higher implementation library such as their

https://github.com/dalek-cryptography/dalek-rangeproofs https://github.com/dalek-cryptography/bulletproofs

And that because of this it doesn't provide any GC functionality memory management needs to be done from the rust code? paging @monsieurleberre for input.

also the dalek-rangeproofs repo says it is archived/readonly/replaced by bullet proofs? can we get clarity if we are implementing this, or using the ed25519-dalek to implement our flavour of range proofs?

[nshCore]

I guess to answer my own question at the end it is the bulletproofs -> https://github.com/catalyst-network/range-proof-wrappers/tree/develop/libs/rust/dalek/bulletproofs-wrapper

[franssl]

I guess it would be applicable to anything available in that library. The problem is that because we have our own signature scheme we need to use some of the functions available there directly. There wouldn't be a problem for the bulletproofs as we can use the higher level library, just the signature creation.

[franssl]

I don't think I understand the reasons given for not using that library directly well enough. I will email the author as you suggested James. I'm still more inclined to use rust, at least for now because I think the same issues such as being able to create invalid points may well also apply to calling the equivalent functions in monero.

[franssl]

I think our options are as follows: 1) Go ahead with implementation of our sig scheme using this lower level rust library, ignoring this warning for now. 2) Implement our sig scheme using the same lower level functions in monero, which may or may not create the same vulnerabilities, or worse considering that rust is generally regarded a more memory safe language. 3) Do as suggested in the readme ffi section of https://github.com/dalek-cryptography/curve25519-dalek, and implement our signature scheme as a higher level rust library. I would be more inclined to do this if we were sure that we wanted to stick with rust longterm. 4) Change our signature scheme to not require these more low level ec functions. We could could create commitments to zero which are just individually signed with a normal ed25519 signature as done in grin.

[nshCore]

I guess it would be applicable to anything available in that library. The problem is that because we have our own signature scheme we need to use some of the functions available there directly. There wouldn't be a problem for the bulletproofs as we can use the higher level library, just the signature creation. :+1:

I don't think I understand the reasons given for not using that library directly well enough. I will email the author as you suggested James. I'm still more inclined to use rust, at least for now because I think the same issues such as being able to create invalid points may well also apply to calling the equivalent functions in monero. :+1:

I think our options are as follows:

Go ahead with implementation of our sig scheme using this lower level rust library, ignoring this warning for now.

:+1:

Implement our sig scheme using the same lower level functions in monero, which may or may not create the same vulnerabilities, or worse

:-1:

considering that rust is generally regarded a more memory safe language.

:+1:

Do as suggested in the readme ffi section of https://github.com/dalek-cryptography/curve25519-dalek, and implement our signature scheme as a higher level rust library. I would be more inclined to do this if we were sure that we wanted to stick with rust longterm.

For reasons you stated rust is design to be have better memory managment && secure since you cant use any points not in a curve. Also for reasons stated in standup I do not what to have to include monero source in our builds along with the technical debt, and being tied to all its dependencies during build.

We should develop this as our underyling library for catalyst long term :+1: :100:

Change our signature scheme to not require these more low level ec functions. We could could create commitments to zero which are just individually signed with a normal ed25519 signature as done in grin.

depends on performance undecided for now