search

LFDT-Lockness / paillier-zk

Zero-knoledge proofs of some paillier cryptosystem properties for use in CGGMP21
Apache License 2.0
1 stars 1 forks source link

Take into account that modpow might not be defined #14

Closed survived closed 1 year ago

survived commented 1 year ago

This PR takes into account that result of BigNumber::modpow might not be defined if exponent is negative. It's done by adding powmod method (that returns Option<BigNumber>) and prohibiting usage of BigNumber::modpow.

It also heavily affects API, as any prove/commit now may return error if modpow is not defined.

survived commented 1 year ago

I noticed that we have InvalidProof error as a public enum. Practically it means that adding a new error path is a breaking change. Client code doesn't need to know why it failed, they're only interested to know whether proof is valid or not. Do you mind if I wrap it into public struct InvalidProof and private enum InvalidProofReason like I did with Error and ErrorReason in this PR?

maurges commented 1 year ago

Hmm, I think I already noted there that the enum is only public for debugging. We might as well hide the enum and only show it through Debug/Display isntances, so go ahead if you want

survived commented 1 year ago

Also there're two InvalidProof errors, should we merge them?

maurges commented 1 year ago

If it makes the implementation of the new InvalidProof easier - sure. They are only used for potential debug anyway, in cggmp we only check is_err currently, right

survived commented 1 year ago

I'm more thinking at API level, it doesn't make much sense to have two InvalidProof types. I'll merge them.

maurges commented 1 year ago

it doesn't make much sense to have two InvalidProof

Well, they have completely different variants, so it makes sense to me.

survived commented 1 year ago

they have completely different variants

All of them are private now, so at API level they're no different