Skip to content

Commit

Permalink
Add recent answers by Nikos
Browse files Browse the repository at this point in the history
  • Loading branch information
fjarri committed Nov 5, 2023
1 parent 5187a9a commit abfb844
Showing 1 changed file with 57 additions and 0 deletions.
57 changes: 57 additions & 0 deletions PAPER.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,37 @@ Replies from Nikos Makriyannis are marked as (NM)
- `Z_N^*`: (NM) all the invertible elements mod N, so it includes 1.
- In Definition 2.2, the `\rho` argument is the randomizer - it should be freshly sampled each time (and therefore it is omitted as an argument when `enc()` is used later in the protocol)
- Intervals: `I = +- 2^l`, `J = +- 2^l_prime`, `I_eps = +- 2^(l + eps)`, `J_eps = +- 2^(l_prime + eps)` (In Section 3, but seems to be present only in the working copy of the paper)
- The subscript `j` in `П^enc`, `П^log` etc (e.g. in Fig. 7) indicates which party's Pedersen parameters -- the tuple `(\hat{N}, s, t)` -- should be used when generating the proof.


# Typos

The randomness derivation (`\mu` in Output, step 1, in Fig. 6) is overly complicated - `\mu = (C mod N)^(N^(-1) mod phi(N))` works just as well. Also, `(1 + N)^m mod N^2 == (1 + m * N) mod N^2`, which is much faster to compute, but I guess the exponential form is conventional.

In `П^{fac}` (Fig. 28), step 2: `q` the curve order, not to be confused with `q` the RSA prime in the Inputs.

In `П^{aff-g}` (Fig. 15) I had to modify the proof to account for how `D` is actually constructed in the Presigning protocol. In the proof it is assumed that `D = C (*) x (+) enc(y)` (where `(*)` and `(+)` are homomorphic operations on Paillier ciphertexts), but in the Presigning it's actually `D = C (*) x (+) enc(-y)` (see Fig. 7, Round 2, step 2). So I had to modify the following:
- (prover) `T = s^{-y} t^\mu \mod \hat{N}`
- (prover) `z_2 = \beta - e y`
- (prover) `\omega_y = r_y \rho_y^{-e} \mod N_1`
- (verifier checks) `enc_1(z_2, \omega_y) = B_y (+) Y (*) (-e)`

In `П^{mul*}`, Fig. 30:
- the prover creates `B_x`, but sends `B` - a typo, and they're the same thing;
- the prover creates `r_y`, but it is unused - a typo;
- `\beta` used to create `A` is not mentioned anywhere else (and judging by the condition the verifier checks, it should be equal to zero) - should be ignored (set to 0).

In Presigning (Fig. 7), Round 2, step 2 `r_{i,j}` and `\hat{r}_{i,j}` should be drawn from `\mathbb{Z}_{N_i}`, and not `N_j`, judging by how they are used later.


# Protocol

Q: `\ell`, `ell_prime`, `\eps`, and corresponding intervals (\mathcal{I} and \mathcal{J}, see e.g. Fig. 7) - what are they equal to? It is mentioned that they will be "determined by the analysis", but I could not find the values specified. I found one mention of the range parameters (and the security parameter `m`): the caption of Table 2 in Appendix D. It gives `m = 80`, `\ell = \kappa`, `\ell^\prime = 5 \kappa`, `\eps = 2 \kappa`, where `\kappa` is the bit length of the curve order, so 256 for secp256k1. Also Fig. 28 in Section C.5 fixes the size of the RSA modulus as `log2(N) = 4 \ell + 2 \eps` (which gives 2048 bit). I'm currently using these as production parameters, but it seems weird that they're hidden in such obscure places.

A (NM): Those are the recommended values.

---

Q: In Fig. 5 the initial commitment in the Schnorr proof (`A_i`) is sent twice (in R2 and then R3, as a part of `psi_i`), and then the equality of those two values is checked in Output, right before checking the proof itself. But the commitment value is used right after that in the `vrfy` step, so if it doesn't match the rest of the proof, the verification will fail. So is there any security reason for sending the commitment twice? (I understand that it does constitute a minor performance optimization)

A (NM): There is no security reason afaict. You could only send it once.
Expand Down Expand Up @@ -71,6 +98,36 @@ Q: Also, in the calculation of `\mu`, what is `N` without the index? Is it suppo

A (NM): It's supposed to be `N_i` (the party that knows the private key for this `N`)

---

Q: During the KeyRefresh/Auxiliary protocol each node generates ring-Pedersen parameters `s` and `t`. I looked through Presigning and all the proofs used there, and they don't seem to be used anywhere. One possibility is that these are actually the setup parameters for the proofs, but then it's strange that the paper doesn't mention generating the corresponding public Paillier key `\hat{N}`. I guess, a possibility is that the Paillier key each node generates *is* the auxiliary setup for ZK proofs. That would certainly make things faster since we would only have to generate one Paillier key instead of two, and that is the slowest part of key refresh.

A (NM): Using the same value for `N` and `\hat{N}` does not affect security as far as we can tell.

---

Q: According to according to "Generating the Setup Parameter for the Range Proofs" in Section 2.3, the setup parameters `(\hat{N}, s, t)` used in several ZK proofs (`fac`, `enc`, `aff-g`, `log*` etc) are generated once by each node separately and then sent to other nodes along with `П^{prm}` and `П^{mod}`. This is not present explicitly in any protocols, so my current theory is that each node generates them once in KeyRefresh/Auxiliary protocol, along with the main Paillier key, and then other nodes use it later in KeyRefresh/Auxiliary and Presigning when creating the proofs. Is that correct?

A (NM): The setup parameters should be chosen afresh with each key-refresh.

---

Q: How does the range limitation in `П^{fac}` (Fig. 28) work? Specifically, how does the range check on `z_1` and `z_2` guarantee `p, q > 2^\ell`? I suppose there's a probabilistic guarantee that `p, q < 2^\eps \sqrt{N_0}`, which, along with the condition `p q = N_0` gives `p, q > 2^\eps` (but then the range check for `z_1` and `z_2` should perhaps be at `\sqrt{N_0} * 2^{\ell + \eps + 1}`).

A (NM): The parties check that `z1,z2 < \pm \sqrt{N0}*2^{\ell+\eps}` which means that `p, q < \pm \sqrt{N0}*2^{\ell+\eps}`. Since `N0` is a biprime (and it only has two factors), it follows that `p,q > 2^\ell` because `N0 \approx 2^{\ell} * \sqrt{N0}*2^{\ell+\eps}`.

---

Q: Speaking of the `p, q > 2^\ell` guarantee in `П^{fac}`: isn't it quite weak, given the value of `\ell` in the production parameters? If one factor of an RSA modulus is 256 bit, it is possible to decompose it in a reasonable time.

A (NM): We want N0 not to have small factors in order for the ZK proofs elsewhere to be sound (it's not related to the hardness of factoring the modulus).

---

Q: What should I take as `\sqrt{N_0}` in `П^{fac}` (Fig. 28)? Lower bound (2^1023), upper bound (2^1024), faithful square root?

A (NM): Either one should be fine.


# Layering

Expand Down

0 comments on commit abfb844

Please sign in to comment.