Test FacProof with bad Paillier keys

[dvdplm]

No description provided.

[fjarri]

Not sure what you mean here, if y = x mod N^2 then y < N^2, which means y / N < N. How does GCD factor in?

[dvdplm]

I honestly no longer remember why I wrote that. Pff. :/

[fjarri]

I think the reason the test passes is that the proof conditions are violated. You're sampling a small p and a regular-sized q, which makes the resulting N_0 to be of size PRIME_BITS + x, instead of 2 * PRIME_BITS. The П_fac assumes N0 ~ 2^(2l + eps) ~ 2^(2 * PRIME_BITS). The size of N_0 would be checked prior to П_fac (See Fig. 6, AuxInfo/KeyRefresh, Round 3, Step 1).

It is not trivial to make the proof fail while keeping the N_0 the proper size, because of the HalfUint limits on p and q (which raises the question of how it should be tested). But if you were to change their types, and have, say q ~ 2^(PRIME_BITS * 2), in the proof (see Fig. 28) you'd get z2 ~ 2^(4l + 2eps) * q, which would fail the range check z2 < 2^(l + eps) * sqrt(N0) ~ 2^(3l + 2eps). l = 256, so the difference would be quite noticeable.

(the references here are to the '21 version of the paper)

[dvdplm]

Maybe all we need to do here is adding a check that N_0 is indeed 2*PRIME_BITS bits long?

I struggle to come up with an attack scenario where the a wrong-size N_0 could slip through the previous rounds, but given that the Paillier secret key is deserializable from bytes (without size checks) it is perhaps wise to adopt a defense in depth approach here.