In LWE based multi party FHE schemes, the parties should choose a much larger noise when perform joint decryption. In this paper, the author just said that using noise flooding technique to avoid the information leakage about the noise of the ciphertext. Then, how should we choose the smudging noise in a real scenario？
In Palisade library, I find that they add noise with 20-bits standard deviation Here, is it enough to guarantee the security？
Using statistical distance yields a crude bound of $\sigma$ noise bits for $\sigma = 2^\lambda$, and Micciancio and Walter's 2018 Eurocrypt paper implies that $\sigma = 2^{\lambda/2}$ is sufficient. Li et al.'s work (https://eprint.iacr.org/2022/816) takes this further and applies it to the $IND-CPA^D$ setting which is the same as the threshold FHE setting, even in BGV/BFV or Regev encryption (we flood to protect the ciphertext noise). Li et al. suggest 47 bits of noise if you can limit the number of queries per ciphertext to $\leq 2^{10}$.
Some more details about the Li et al. paper: they separate the computational security from statistical security described in-detail in Section 4.4. They call this $(\lambda,s)$ where a scheme uses a $\lambda$-bit secure computational assumption (e.g., RLWE) and a $s$-bit secure statistical assumption (regardless of an adversary's time resources). That is, $s$ means that any adversary has at most $2^{-s}$ success probability. Here is where they argue that just under 47 bits of noise flooding is secure in most RLWE settings. This is from the formula $$ \sigma = \sqrt{24n\alpha}2^{s/2} $$ where $\alpha$ is the number of adversarial threshold decryption queries per ciphertext, $n$ is the RLWE ring dimension, and $s$ is the statistical security (an adversary has $2^{-s}$ chance of success). Let $n = 2^{15}$ and restrict $\alpha = 1$, then this is about $10 + s/2$ bits for $\sigma$. So, 20 bits in PALISADE corresponds to roughly $2^{-20}$ ($s=20$) success chance for any adversary (somewhat high). Li et al. suggest 47 bits because they set $\alpha = 2^{10}$, $n=2^{15}$, and $s=64$.
A large sigma really only effects performance when using CKKS, since you want the message and the noise to be under $64$ bits so you can use the RNS version with 64-bit native arithmetic. BGV/BFV or Regev encryption aren't as effected since you can just threshold decrypt with an extra RNS modulus or two. I know openFHE (https://www.openfhe.org/) has a 128-bit backend for CKKS. This would allow for a large $\sigma$ and lots of bits of precision for the message in CKKS at a 4-8x slowdown.
