Merge pull request #408 from helibproject/master

Public Dev Sync-5 December 2020, CKKS mitigation

Author: shaih

CHANGES.md

@@ -1,3 +1,13 @@
+HElib 1.3.0, December 2020
+=========================
+(tagged as v1.3.0)
+
+November-December 2020
+---------------------
+* Mitigation for the CKKS vulnerability recently [observed](https://eprint.iacr.org/2020/1533.pdf) by Li and Micciancio
+* Context Builder unsing builder pattern
+* HElib now requires C++17
+
 HElib 1.2.0, November 2020
 =========================
 (tagged as v1.2.0)

CKKS-security.md

@@ -0,0 +1,63 @@
+# Security of Approximate-Numbers Homomorphic Encryption
+
+Security of standard (not homomorphic) encryption scheme is fairly well understood nowadays, and it usually comes in two flavors: An encryption scheme may only resists passive attackers (that can view encrypted data but not manipulate it), or it can also resist active attackers that can manipulate the encrypted data and then observe how it is decrypted.
+The crypto lingo for the weaker (passive) notion is [CPA-security](https://en.wikipedia.org/wiki/Chosen-plaintext_attack), while the stronger is called [CCA-security](https://en.wikipedia.org/wiki/Chosen-ciphertext_attack). (These acronyms stand for chosen-plaintext-attacks and chosen-ciphertext-attacks, respectively.)
+It is well understood that to protect data at rest or in transit, one must use CCA-secure encryption. CPA-security may suffice when the encryption is used as one component in a larger system, and protection against active attackers is provided by other components in that system.
+
+For homomorphic encryption (HE) schemes, it is well known that they inherently cannot be CCA secure. One consequence of their non-CCA-security is that the system must ensure that decryption is never applied to invalid ciphertexts.<sup>[1](#validCtxt)</sup> Indeed, with contemporary HE schemes, allowing the attacker to submit invalid ciphertexts to be decrypted would typically result in exposure of the secret key. It is thus a commonly accepted practice for HE schemes to make do with CPA security, and rely on the system around the HE to provide the extra protection that may be needed.
+
+Recently, Li and Micciancio [observed](https://eprint.iacr.org/2020/1533) that for *approximate-number* HE schemes, the common notion of CPA security may not be enough even against passive attackers. The crucial difference is that since the scheme itself adds some error, the attacker could learn something from the decryption result *even if it knows what the decrypted result was supposed to be*. Specifically, it learns the error, which may leak information about the secret key. Li and Micciancio described simple attacks on the CKKS approximate-numbers scheme that expose the secret key after seeing a small number of decryption results (sometimes as few as a single decryption).
+
+## Mitigating the Li-Micciancio attacks
+
+In response to this observation, HElib now includes countermeasures to mitigate this risk. In particular, the HElib decryption routine for CKKS was modified to add some key-independent noise, masking the key-dependent noise and making the Li-Micciancio attacks harder to mount. This extra noise, however, reduces the accuracy of the decrypted result. By default, the magnitude of this key-independent noise is chosen equal to the noise-bound that HElib keeps for the ciphertext to be decrypted, but that bound may be over-conservative and hence the added noise could sometimes cause a significant decrease in accuracy. HElib therefore provides the application the means to specify the required accuracy on decryption, and will then add the largest amount of noise subject to this accuracy constraint.
+
+Applications that use CKKS need to walk a fine line, balancing security, accuracy, and performance. Below we describe a framework for developing CCKS-based applications while taking these aspect into account. Roughly, we recommend that the application try to get a tight estimate for the error, and then use that estimate instead of the noise bound that HElib computes.
+
+1. Start by identifying the (class of) processes that the application needs to apply to the data;
+2. Identify the *required precision* from the processed results;
+3. Run these processes in HElib on test data to determine the parameters to be used, roughly as follows:
+   1. Find some parameter setting where `context.securityLevel()` returns high enough security and the library does not report decryption errors;
+   2. Experimentally find a fairly tight bound on the noise magnitude of the decrypted results, when called with the accuracy parameter from Step 2. This can be done by running HElib processing many times and comparing the decrypted results to what you get when applying the same processing to plaintext data;
+   3. Compare the noise bounds that you get from Step 3.2 above with the estimated error that HElib computes just prior to decryption, which can be accessed via `ctxt.errorBound()`. If the experimental noise is significantly smaller than what `ctxt.errorBound()` returns then use `ctxt.bumpNoiseBound()` prior to decryption to force HElib to use the tighter error estimate.
+   4. Repeat Steps 3.1-3.3, increasing the parameters until decryption no longer emits a warning about the added noise being too small.
+
+We now elaborate more on each of these steps.
+
+### Steps 1-2, Processes and Required Precision
+
+As with any application of HE, the starting point is ensuring adequate functionality. The developers must therefore determine the operations to be computed and the required *output precision*. Some applications only need to compute a single function while others need to handle a wider class of functions, but at the very least the developers should determine the maximum depth of supported circuits and the maximum precision required.
+
+In HElib, the application gets to specify the *input precision* for encrypting plaintext data, and each level in the circuit reduces the precision by one (or upto 1.5) bits, namely the error roughly doubles for each level. For example using the helper class `PtxtArray` one could call `ptxt.encrypt(ctxt, ptxtMagnitude, precision)`,<sup>[2](#optPrecision)</sup> which would result in encryption of the given input plaintext with error bounded by 2<sup>-precision</sup>.
+After evaluating a depth-three circuit (say), the error will grow to a little more than 2<sup>3-precision</sup>. An application requiring *p* bits of output precision after the evaluation of a depth-*d* circuit should then encrypt with input precision somewhere between *p+d* and *p+3d/2*.
+
+### Step 3, Finding Matching Parameters
+
+After determining the required depth *d* and output precision *p*, the application developers need to find some parameters that yield this output precision while ensuring security. This typically involves an iterative trial-and-error procedure, as follows:
+
+1. Begin with some rough estimate of the parameters: The total bitlength of the modulus needed for a depth-*d* circuit is typically something like *22(d+1)*, and the ring dimension needed to get 128-bit security with this modulus is around *750(d+1)* (rounded up to a power of two, since the current CKKS support in HElib was only tested with power-of-two rings).
+
+   Denote by *m* the next power of two larger than *750(d+1)*, then these initial parameters can be set in HElib by using the `ContextBuilder` class, setting
+   ```
+     Context context =
+         ContextBuilder<CKKS>().m(m).bits(16*(d+1)).precision(p+d).c(3).build();
+   ```
+   Note that the number of bits specified above is only *16(d+1)* rather than *22(d+1)*, and there is a mysterious additional parameter *c=3* satisfying *(c+1)/c ~ 22/16*. The quantity *bits=16(d+1)* is an estimate for what's needed for a depth-*d* circuit, and the total modulus bitsize in HElib is obtained roughly as *bits&middot;(c+1)/c*. (See discussion of *ciphertext vs. special primes* in the [HElib document](https://eprint.iacr.org/2020/1481), section 5.1.) One can get slightly smaller total bitsize for the same functionality by increasing the *c* parameter from its default value of *c=3*, but the keysize and running time grow almost linearly with *c*.
+
+   After setting these parameters, run HElib processing and check if the library complains about possible decryption errors, and use these experiments to increase or decrease the *bits* and *m* parameters. You should also use the interface `context.securityLevel()` to check that this combination of parameters *m,bits,precision* and *c* yields an acceptable level of security.
+
+2. Check that these parameters indeed yield the required output precision. Namely run several experiments of HElib processing, decrypting the result with the optional precision argument (e.g., using the interface `ptxt.rawDecrypt(ctxt, secretKey)` of the `ptxtArray` class), and comparing the outcome with the result of plaintext processing. (At this point you should ignore any warning from HEib about the added noise being too small.) Revisit the parameters from Step 1 above until both security and output precision are acceptable.
+
+3. Next, check the error bound that HElib reports via `ctxt.errorBound()` just prior to decryption, to the actual error that was observed in the previous step (which presumably is no more than *2<sup>-p</sup>*). If the HElib estimate is significantly larger than the actual noise, then use `ctxt.bumpNoiseBound()` prior to decryption to force HElib to use the "right estimate".
+
+4. At this point, you need to switch to using `ptxt.decrypt(ctxt, secretKey, p)` and check that HElib no longer emits a warning message on decryption about the added noise being too small. If you still see that warning, then you need to revisit the parameter setting, increasing the *bits* parameter (and other parameters as needed to maintain security and precision), until this warning is no longer displayed.
+
+As a final comment, we remark that this procedure is only adequate for cases where the threat model include the adversary only getting access to a handful of decryption results. If the total amount of information available to the adversary about decryption queries is much larger, then the application needs to increase the *bits* parameter from above. In particular, to withstand an attack that has access to the results from decryption of *D* ciphertexts, the *bits* parameter should be increased roughly by a factor of *<math><msqrt><mi>D</mi></msqrt></math>*, and the input-precision parameter should similarly be increased to *<math><msqrt><mi>D</mi></msqrt>(p+d)</math>*.
+
+---------------------------------------
+<a name="validCtxt"><sup>1</sup></a>
+In HElib, a ciphertext is *valid* if it was produced using the library's encryption and evaluation routines and does not contain too much noise. In particular, decryption using should not emit a warning about "decrypting with too much noise".
+
+<a name="optPrecision"><sup>2</sup></a>
+The `ptxtMagnitude`, and `precision` arguments are optional, with defaults that depend on the context and the actual plaintext to be encrypted. Importantly, the precision (if specified) indicates an absolute number, *not* a fraction of the plaintext magnitude. For example calling with `precision=3` yields an error of magnitude 1/8, whether it is called with `ptxtMagnitude=16`, and `ptxtMagnitude=1`. Finally note that the `precision` arguments can also be negative, indicating error magnitude larger than one.
+

CMakeLists.txt

@@ -19,8 +19,8 @@ if (NOT (CMAKE_SIZEOF_VOID_P EQUAL 8))
   message(FATAL_ERROR "HElib requires a 64-bit architecture.")
 endif ()
 
-# Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
+# Use -std=c++17 as default.
+set(CMAKE_CXX_STANDARD 17)
 # Disable C++ extensions
 set(CMAKE_CXX_EXTENSIONS OFF)
 # Require full C++ standard

README.md

@@ -12,6 +12,9 @@ the [Smart-Vercauteren][2] ciphertext packing techniques and
 the [Gentry-Halevi-Smart][3] optimizations. See [this report][7] for a
 description of a few of the algorithms using in this library. 
 
+Please refer to [CKKS-security.md](CKKS-security.md) for the latest 
+discussion on the security of the the CKKS scheme implementation in HElib.
+
 Since mid-2018 HElib has been under extensive refactoring for *Reliability*, 
 *Robustness & Serviceability*, *Performance*, and most importantly *Usability* 
 for researchers and developers working on HE and its uses.

benchmarks/CMakeLists.txt

@@ -12,8 +12,8 @@
 
 cmake_minimum_required(VERSION 3.10.2 FATAL_ERROR)
 
-## Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
+## Use -std=c++17 as default.
+set(CMAKE_CXX_STANDARD 17)
 ## Disable C++ extensions
 set(CMAKE_CXX_EXTENSIONS OFF)
 ## Require full C++ standard

examples/BGV_binary_arithmetic/CMakeLists.txt

@@ -9,19 +9,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License. See accompanying LICENSE file.
 
-cmake_minimum_required(VERSION 3.10.2 FATAL_ERROR)
-
-# Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
-# Disable C++ extensions
-set(CMAKE_CXX_EXTENSIONS OFF)
-# Require full C++ standard
-set(CMAKE_CXX_STANDARD_REQUIRED ON)
-
-project(BGV_binary_arithmetic LANGUAGES CXX)
-
-find_package(helib 1.1.0 EXACT REQUIRED)
-
 add_executable(BGV_binary_arithmetic BGV_binary_arithmetic.cpp)
 
 target_link_libraries(BGV_binary_arithmetic helib)

examples/BGV_country_db_lookup/CMakeLists.txt

@@ -9,21 +9,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License. See accompanying LICENSE file.
 
-cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
-
-## Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
-## Disable C++ extensions
-set(CMAKE_CXX_EXTENSIONS OFF)
-## Require full C++ standard
-set(CMAKE_CXX_STANDARD_REQUIRED ON)
-
-project(BGV_country_db_lookup
-       	LANGUAGES CXX)
-
-      find_package(helib 1.1.0 EXACT REQUIRED)
-
 add_executable(BGV_country_db_lookup BGV_country_db_lookup.cpp)
 
 target_link_libraries(BGV_country_db_lookup helib)
-

examples/BGV_packed_arithmetic/CMakeLists.txt

@@ -9,19 +9,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License. See accompanying LICENSE file.
 
-cmake_minimum_required(VERSION 3.10.2 FATAL_ERROR)
-
-# Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
-# Disable C++ extensions
-set(CMAKE_CXX_EXTENSIONS OFF)
-# Require full C++ standard
-set(CMAKE_CXX_STANDARD_REQUIRED ON)
-
-project(BGV_packed_arithmetic LANGUAGES CXX)
-
-find_package(helib 1.1.0 EXACT REQUIRED)
-
 add_executable(BGV_packed_arithmetic BGV_packed_arithmetic.cpp)
 
 target_link_libraries(BGV_packed_arithmetic helib)

examples/CMakeLists.txt

@@ -11,8 +11,8 @@
 
 cmake_minimum_required(VERSION 3.10.2 FATAL_ERROR)
 
-## Use -std=c++14 as default.
-set(CMAKE_CXX_STANDARD 14)
+## Use -std=c++17 as default.
+set(CMAKE_CXX_STANDARD 17)
 ## Disable C++ extensions
 set(CMAKE_CXX_EXTENSIONS OFF)
 ## Require full C++ standard

include/helib/Context.h

@@ -27,8 +27,6 @@
 
 #include <NTL/Lazy.h>
 
-#define FHE_DISABLE_CONTEXT_CONSTRUCTOR
-
 namespace helib {
 
 constexpr int MIN_SK_HWT = 120;
@@ -38,7 +36,7 @@ constexpr int BOOT_DFLT_SK_HWT = MIN_SK_HWT;
  * @brief An estimate for the security-level. This has a lower bound of 0.
  * @param n LWE dimension.
  * @param log2AlphaInv Variable containing the value of `log(1/alpha)` where
- * `alpha` is the noise.
+ * `alpha` is the noise/modulus ratio.
  * @param hwt The Hamming weight.
  * @return The estimated security level.
  * @note This function uses experimental affine approximations to the
@@ -137,15 +135,28 @@ class ContextBuilder;
  **/
 class Context
 {
+private:
+  template <typename SCHEME>
+  friend class ContextBuilder;
+
+  // Forward declarations of useful param structs for Context and
+  // ContextBuilder.
+  struct ModChainParams;
+  struct BootStrapParams;
+
   std::vector<Cmodulus> moduli; // Cmodulus objects for the different primes
   // This is private since the implementation assumes that the list of
   // primes only grows and no prime is ever modified or removed.
 
-public:
-  // Here are some "getter" methods that give direct
-  // access to important parameters.  These are for convenience,
-  // as well as allowing for future re-organization.
+  Context(long m,
+          long p,
+          long r,
+          const std::vector<long>& gens,
+          const std::vector<long>& ords,
+          const std::optional<ModChainParams>& mparams,
+          const std::optional<BootStrapParams>& bparams);
 
+public:
   // Parameters stored in zMStar.
   // These are invariant for any computations involving this Context
 
@@ -512,49 +523,33 @@ class Context
           const std::vector<long>& gens = std::vector<long>(),
           const std::vector<long>& ords = std::vector<long>());
 
-  // FIXME: This is a temporary fix to allow proper copy of the context.
-  // Without the fixes there would be discrepancies between context's zMStar and
-  // alMod const reference one.
-  // TODO: Add doxygen comments to the following methods.
   /**
    * @brief Default destructor.
    **/
   ~Context() = default;
 
-#ifdef FHE_DISABLE_CONTEXT_CONSTRUCTOR
   /**
-   * @brief Default copy constructor.
+   * @brief Deleted copy constructor.
    * @param other `Context` to copy.
    **/
   Context(const Context& other) = delete;
 
   /**
-   * @brief Default move constructor.
-   * @param other `Context` to copy.
+   * @brief Deleted move constructor.
+   * @param other `Context` to move.
    **/
   Context(Context&& other) = delete;
 
-  template <typename SCHEME>
-  explicit Context(const ContextBuilder<SCHEME>&);
-  // Marked explicit to avoid dangerous implicit conversions.
-
-#else
-
   /**
-   * @brief Default copy constructor.
+   * @brief Deleted copy assignment.
    * @param other `Context` to copy.
    **/
-  Context(const Context& other);
+  Context& operator=(const Context& other) = delete;
 
   /**
-   * @brief Default move constructor.
-   * @param other `Context` to copy.
+   * @brief Deleted move assignment.
+   * @param other `Context` to move.
    **/
-  Context(Context&& other);
-#endif
-
-  // Deleted assignment operators.
-  Context& operator=(const Context& other) = delete;
   Context& operator=(Context&& other) = delete;
 
   /**
@@ -967,6 +962,11 @@ class ContextBuilder
                 "scheme (CKKS or BGV)");
 
 private:
+  // Helper for building
+  const std::pair<std::optional<Context::ModChainParams>,
+                  std::optional<Context::BootStrapParams>>
+  makeParamsArgs() const;
+
   // Default values by scheme.
   struct default_values;
 
@@ -1157,6 +1157,20 @@ class ContextBuilder
     return *this;
   }
 
+  /**
+   * @brief Sets `mvec` the unique primes which are factors of `m`.
+   * @param mvec A `std::vector` of primes factors.
+   * @return Reference to the `ContextBuilder` object.
+   * @note Only exists when the `SCHEME` is `BGV`.
+   **/
+  template <typename S = SCHEME,
+            std::enable_if_t<std::is_same<S, BGV>::value>* = nullptr>
+  ContextBuilder& mvec(const std::vector<long>& mvec)
+  {
+    mvec_ = convert<NTL::Vec<long>>(mvec);
+    return *this;
+  }
+
   /**
    * @brief Sets boostrapping to be `thin`.
    * @return Reference to the `ContextBuilder` object.
@@ -1219,15 +1233,14 @@ class ContextBuilder
    * `ContextBuilder` object.
    * @return A `Context` object.
    **/
-#ifdef FHE_DISABLE_CONTEXT_CONSTRUCTOR
-
-  // compatibility interface
-  ContextBuilder& build() { return *this; }
-
-  friend class Context;
-#else
   Context build() const;
-#endif
+
+  /**
+   * @brief Builds a `Context` object from the arguments stored in the
+   * `ContextBuilder` object.
+   * @return A raw pointer to a `Context` object.
+   **/
+  Context* buildPtr() const;
 
   friend std::ostream& operator<<<SCHEME>(std::ostream& os,
                                           const ContextBuilder& cb);