Some questions about Silver

[addingIce]

Hi, I have some questions about Silver:

1. Does this warning means that Silver is not security ? Is there any paper about it ?

   if (gSilverWarning)
               {
                   std::cout << oc::Color::Red << "WARNING: This program made use of the LPN silver encoder. "
                       << "This encoder is experimental and should not be used in production."
                       << " Rebuild libOTe with `-DNO_SILVER_WARNING=TRUE` to disable this message or build the library with "
                       << "`-DENABLE_BITPOLYMUL=TRUE` to use an encoding with provable minimum distance. "
                       << LOCATION << oc::Color::Default << std::endl;
               }

2. Were there any papers about the following two ways of getting mNumPartitions ?

   //u64 secLevel(u64 scale, u64 n, u64 points)
   //{
   //    auto x1 = std::log2(scale * n / double(n));
   //    auto x2 = std::log2(scale * n) / 2;
   //    return static_cast<u64>(points * x1 + x2);
   //}
   
   //u64 getPartitions(u64 scaler, u64 n, u64 secParam)
   //{
   //    if (scaler < 2)
   //        throw std::runtime_error("scaler must be 2 or greater");
   
   //    u64 ret = 1;
   //    auto ss = secLevel(scaler, n, ret);
   //    while (ss < secParam)
   //    {
   //        ++ret;
   //        ss = secLevel(scaler, n, ret);
   //        if (ret > 1000)
   //            throw std::runtime_error("failed to find silent OT parameters");
   //    }
   //    return roundUpTo(ret, 8);
   //}
   
   // We get e^{-2td} security against linear attacks, 
   // with noise weigh t and minDist d. 
   // For regular we can be slightly more accurate with
   //    (1 − 2d)^t
   // which implies a bit security level of
   // k = -t * log2(1 - 2d)
   // t = -k / log2(1 - 2d)
   u64 getRegNoiseWeight(double minDistRatio, u64 secParam)
   {
       if (minDistRatio > 0.5 || minDistRatio <= 0)
           throw RTE_LOC;
   
       auto d = std::log2(1 - 2 * minDistRatio);
       auto t = std::max<u64>(128, -double(secParam) / d);
   
       return roundUpTo(t, 8);
   }

3. There are some different MultType, what are there corresponding papers ?

[ladnir]

1) silver is indeed not secure https://eprint.iacr.org/2023/882

However, this was a recent development and the warning was there from the when silver was first released. This was because it was a very aggressive design which we were not sure of. The Silver paper also suggestion caution when using it.

There is a new construction, expand convolute codes, detailed in the link above as well. This new code was pushed to the repo today. The code have provable minimum distance (the thing that silver was conjectured to have but does not). Thats is to say, the security of silent OT/VOLE with expand convolute has strong security gurarrantees. Quasi cyclic, expand accumulate codes also have provable minimum distance.

2) getPartitions was the approach described by the original silentOT paper, https://eprint.iacr.org/2019/1159.pdf. Im not sure how wel it was detailed but should be implied if not explicitly stated.

getRegNoiseWeight is a more fine grained approach that takes as input the minimum distance of the code that is being used (eg. quasi cyclic, expand accumulate, expand convolute) and returns the required weight of the noise vector to provable prevent linear attacks (i.e. essentially all attacks that are known). This formula was first stated by the expand accumulate paper, https://eprint.iacr.org/2022/1014.

3) at this point you probably can answer this question:

slv5, slv11 => silver QuasiCyclic => the original silentOT paper which suggestions using quasi cyclic codes https://eprint.iacr.org/2019/1159.pdf. ExAcc5,7,... => expand accumulate codes with expantion weight 5,7,..., https://eprint.iacr.org/2022/1014. Using ExAcc no longer makes sense given expand convolute. ExConv => expand convolute codes. The best option for performance and security.

[addingIce]

Thank you for your detailed explanation.