github/Sunscreen
1
1
Fork 0
mirror of https://github.com/Sunscreen-tech/Sunscreen.git synced 2026-01-09 13:48:06 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fix clippy warnings (#381)

Browse Source
This commit is contained in:
Ryan Orendorff
2024-11-20 16:33:25 -07:00
committed by GitHub
parent 6d9639e886
commit 5eba25a961
16 changed files with 84 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
examples/dot_prod/src/main.rs
View File

@@ -20,8 +20,8 @@ const VECLENDIV2: usize = 4096;
* Writing the implementation generically allows us to:
* * Run it without using FHE.
* * Share the implementation for different data types. Imagine we
* had another encryption scheme that supported Batched, this implementation
* would work for that as well!
* had another encryption scheme that supported Batched, this implementation
* would work for that as well!
*/
fn dot_product_impl<T>(a: T, b: T) -> T
where

8
logproof/src/assertions.rs
View File

@@ -276,10 +276,10 @@ pub mod linear_relation {
* The identity is given below (compile docs with mathjax support to view):
*
* $
* \left<\mathbf{A}(\alpha)^T \vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_d \otimes \vec{2}_b, \mathrm{Binary}_b(\vec{s})\right>
* + \left<q\vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_{2d-1} \otimes \vec{2}_{b_1}, \mathrm{Binary}_{b_1}(\vec{r_1}) \right>
* + \left< \mathbf{f}(\alpha)\vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_{d-1} \otimes \vec{2}_{b_2}, \mathrm{Binary}_{b_2}(\vec{r_2}) \right>
* = \vec{\gamma}^T \mathbf{T}(\alpha)\vec{\beta}
* \left<\mathbf{A}(\alpha)^T \vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_d \otimes \vec{2}_b, \mathrm{Binary}_b(\vec{s})\right> +
* \left<q\vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_{2d-1} \otimes \vec{2}_{b_1}, \mathrm{Binary}_{b_1}(\vec{r_1}) \right> +
* \left< \mathbf{f}(\alpha)\vec{\gamma} \otimes \vec{\beta} \otimes \vec{\alpha}_{d-1} \otimes \vec{2}_{b_2}, \mathrm{Binary}_{b_2}(\vec{r_2}) \right> =
* \vec{\gamma}^T \mathbf{T}(\alpha)\vec{\beta}
* $
*/
pub fn assert_equation_19<Q>(

4
logproof/src/lib.rs
View File

@@ -3,9 +3,9 @@
//! This crate contains proofs for demonstrating facts about lattice
//! relations in zero knowledge. It contains 2 proofs:
//! * [InnerProductProof], which is basically the Bulletproofs inner product
//! proof modified to be zero-knowledge.
//! proof modified to be zero-knowledge.
//! * [LogProof], which demonstrates knowledge of a solution to a lattice
//! relation `As=t`, where `A`, `s`, `t` are in `Z_q[X] / f(X)`.
//! relation `As=t`, where `A`, `s`, `t` are in `Z_q[X] / f(X)`.
//!
//! # Remarks
//! These proofs come from "Short Discreet Log Proofs for FHE and Ring-LWE

6
seal_fhe/src/context.rs
View File

@@ -56,9 +56,9 @@ impl Context {
*
* * `params` - The encryption parameters.
* * `expand_mod_chain` - Determines whether the modulus switching chain
* should be created.
* should be created.
* * `security_level` - Determines whether a specific security level should be
* enforced according to HomomorphicEncryption.org security standard.
* enforced according to HomomorphicEncryption.org security standard.
*/
pub fn new(
params: &EncryptionParameters,
@@ -86,7 +86,7 @@ impl Context {
*
* * `params` - The encryption parameters.
* * `expand_mod_chain` - Determines whether the modulus switching chain
* should be created.
* should be created.
*/
#[cfg(feature = "insecure-params")]
pub fn new_insecure(params: &EncryptionParameters, expand_mod_chain: bool) -> Result<Self> {

16
seal_fhe/src/encryptor_decryptor.rs
View File

@@ -230,8 +230,8 @@ impl<T: marker::Asym> Encryptor<T> {
* The encryption parameters for the resulting ciphertext correspond to:
* 1) in BFV, the highest (data) level in the modulus switching chain,
* 2) in CKKS, the encryption parameters of the plaintext.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
*
* * `plainext` - The plaintext to encrypt.
*/
@@ -261,8 +261,8 @@ impl<T: marker::Asym> Encryptor<T> {
* The encryption parameters for the resulting ciphertext correspond to:
* 1) in BFV, the highest (data) level in the modulus switching chain,
* 2) in CKKS, the encryption parameters of the plaintext.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
*
* * `plainext` - The plaintext to encrypt.
*/
@@ -408,8 +408,8 @@ impl<T: marker::Sym> Encryptor<T> {
* The encryption parameters for the resulting ciphertext correspond to:
* 1) in BFV, the highest (data) level in the modulus switching chain,
* 2) in CKKS, the encryption parameters of the plaintext.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
* Dynamic memory allocations in the process are allocated from the memory
* pool pointed to by the given MemoryPoolHandle.
*
* * `plainext` - The plaintext to encrypt.
*/
@@ -482,8 +482,8 @@ impl<T: marker::Sym> Encryptor<T> {
/// The encryption parameters for the resulting ciphertext correspond to:
/// 1) in BFV, the highest (data) level in the modulus switching chain,
/// 2) in CKKS, the encryption parameters of the plaintext.
/// Dynamic memory allocations in the process are allocated from the memory
/// pool pointed to by the given MemoryPoolHandle.
/// Dynamic memory allocations in the process are allocated from the memory
/// pool pointed to by the given MemoryPoolHandle.
///
/// * `plainext` - The plaintext to encrypt.
pub fn encrypt_symmetric_return_components(

10
seal_fhe/src/plaintext_ciphertext.rs
View File

@@ -187,19 +187,19 @@ impl Plaintext {
* rules:
* 1. Terms are listed in order of strictly decreasing exponent
* 2. Coefficient values are non-negative and in hexadecimal format (upper
* and lower case letters are both supported)
* and lower case letters are both supported)
* 3. Exponents are positive and in decimal format
* 4. Zero coefficient terms (including the constant term) may be (but do
* not have to be) omitted
* not have to be) omitted
* 5. Term with the exponent value of one must be exactly written as x^1
* 6. Term with the exponent value of zero (the constant term) must be written
* as just a hexadecimal number without exponent
* as just a hexadecimal number without exponent
* 7. Terms must be separated by exactly \[space\]+\[space\] and minus is not
* allowed
* allowed
* 8. Other than the +, no other terms should have whitespace
*
* * `hex_str`: The formatted polynomial string specifying the plaintext
* polynomial.
* polynomial.
*
* # Panics
* Panics if `hex_str` contains a null character anywhere but the end of the string.

8
sunscreen/src/types/bfv/batched.rs
View File

@@ -46,11 +46,11 @@ use sunscreen_runtime::{Error as RuntimeError, Result as RuntimeResult};
* wrap around rather than truncate. The Batched type exposes these as the
* `<<`, `>>`, and `swap_rows` operators:
* * `x << n`, where n is a u64 rotates each row n places to the left.
* For example, `[0, 1, 2, 3; 4, 5, 6, 7] << 3` yields
* `[3, 0, 1, 2; 7, 4, 5, 6]` (note that real vectors have many more
* columns).
* For example, `[0, 1, 2, 3; 4, 5, 6, 7] << 3` yields
* `[3, 0, 1, 2; 7, 4, 5, 6]` (note that real vectors have many more
* columns).
* * `x << n`, where n is a u64 rotates each lane n places to the left.
* For example, `[0, 1, 2, 3; 4, 5, 6, 7] >> 1` yields `[3, 0, 1, 2; 7, 4, 5, 6]`.
* For example, `[0, 1, 2, 3; 4, 5, 6, 7] >> 1` yields `[3, 0, 1, 2; 7, 4, 5, 6]`.
* * `x.swap_rows()` swaps the rows. For example, `[0, 1, 2, 3; 4, 5, 6, 7].swap_rows()` yields `[4, 5, 6, 7; 0, 1, 2, 3]`.
*
* # Performance

18
sunscreen/src/types/bfv/fractional.rs
View File

@@ -107,7 +107,7 @@ use std::ops::*;
* * The underlying [`f64`] is infinite.
* * The underlying [`f64`] is NaN
* * The integer portion of the underlying [`f64`] exceeds the precision for
* `INT_BITS`
* `INT_BITS`
*
* Subnormals flush to 0, while normals are represented without precision loss.
*
@@ -126,13 +126,13 @@ use std::ops::*;
*
* To mitigate these issues, you should do some mix of the following:
* * Ensure inputs never result in either of these scenarios. Inputs to a
* FHE program need to have small enough digits to avoid digit overflow, values
* are small enough to avoid integer underflow, and have few enough decimal
* places to avoid decimal underflow.
* FHE program need to have small enough digits to avoid digit overflow, values
* are small enough to avoid integer underflow, and have few enough decimal
* places to avoid decimal underflow.
* * Alice can periodically decrypt values, call turn the [`Fractional`] into
* an [`f64`], turn that back into a [`Fractional`], and re-encrypt. This will
* propagate carries and truncate the decimal portion to at most 53
* places (radix 2).
* an [`f64`], turn that back into a [`Fractional`], and re-encrypt. This will
* propagate carries and truncate the decimal portion to at most 53
* places (radix 2).
*
* ```rust
* # use sunscreen::types::bfv::Fractional;
@@ -154,9 +154,9 @@ use std::ops::*;
*
* Overflow aside, decryption can result in more acceptable and exprected precision loss:
* * If `INT_BITS > 1024`, the [`Fractional`]'s int can exceed [`f64::MAX`],
* resulting in [`f64::INFINITY`].
* resulting in [`f64::INFINITY`].
* * Decrypion will truncate precision beyond the 53 floating point mantissa bits (52 for subnormals). As previously mentioned, encrypting a subnormal
* flushes to 0.
* flushes to 0.
*/
pub struct Fractional<const INT_BITS: usize> {
val: f64,

41
sunscreen/src/types/mod.rs
View File

@@ -16,29 +16,30 @@
* provides types that transparently encode data you might actually want
* to use into and out of polynomials. These include:
* * The [`Signed`](crate::types::bfv::Signed) type represents a signed integer that
* encodes a binary value decomposed into a number of digits. This encoding
* allows for somewhat efficiently representing integers, but has unusual
* overflow semantics developers need to understand. This type supports
* addition, subtraction, multiplication, and negation.
* encodes a binary value decomposed into a number of digits. This encoding
* allows for somewhat efficiently representing integers, but has unusual
* overflow semantics developers need to understand. This type supports
* addition, subtraction, multiplication, and negation.
* * The [`Fractional`](crate::types::bfv::Fractional) type is a quasi fixed-point
* value. It allows you to homomorphically compute decimal values as
* efficiently as the [`Signed`](crate::types::bfv::Signed) type. This type has complex overflow
* conditions. This type intrinsically supports homomorphic addition
* multiplication, and negation. Dividing by an [`f64`] constant is supported.
* Dividing by ciphertext is not possible.
* value. It allows you to homomorphically compute decimal values as
* efficiently as the [`Signed`](crate::types::bfv::Signed) type. This type has complex overflow
* conditions. This type intrinsically supports homomorphic addition
* multiplication, and negation. Dividing by an [`f64`] constant is supported.
* Dividing by ciphertext is not possible.
* * The [`Rational`](crate::types::bfv::Rational) type allows quasi fixed-point
* representation. This type interally uses 2 ciphertexts, and is thus requires
* twice as much space as other types. Its overflow semantics are effectively
* those of two [`Signed`](crate::types::bfv::Signed) values. However, this type is
* less efficient than [`Fractional`](crate::types::bfv::Fractional), as it
* requires 2 multiplications for addition and subtraction. Unlike other types,
* [`Rational`](crate::types::bfv::Rational) supports ciphertext-ciphertext
* division.
* representation. This type interally uses 2 ciphertexts, and is thus requires
* twice as much space as other types. Its overflow semantics are effectively
* those of two [`Signed`](crate::types::bfv::Signed) values. However, this type is
* less efficient than [`Fractional`](crate::types::bfv::Fractional), as it
* requires 2 multiplications for addition and subtraction. Unlike other types,
* [`Rational`](crate::types::bfv::Rational) supports ciphertext-ciphertext
* division.
* * The [`Batched`](crate::types::bfv::Batched) type packs thousands of signed integers
* into lanes by exploiting the Chinese remainder theorem for cyclotomic polynomials.
* Arithmetic operations semantically execute per-lane, enabling high-throughput;
* e.g. a single addition operation `a + b` will element-wise add the many lanes of a to the
* many lanes in b.
* into lanes by exploiting the Chinese remainder theorem for cyclotomic polynomials.
* Arithmetic operations semantically execute per-lane, enabling high-throughput;
* e.g. a single addition operation `a + b` will element-wise add the many lanes of a to the
* many lanes in b.
*
* Type comparison:
*
* | Type | # ciphertexts | overflow conditions | values | ops/add | ops/mul | ops/sub | ops/neg | ops/div |

2
sunscreen_backend/src/lib.rs
View File

@@ -4,7 +4,7 @@
//! This crate contains the backend compiler for sunscreen FHE programs. It includes the
//! following useful operations:
//! * [`compile`] takes either an FHE program from the compiler frontend and applies a set
//! of transformations.
//! of transformations.
mod error;
/**

2
sunscreen_curve25519

Submodule sunscreen_curve25519 updated: 1c54925005...7bab11b3d6

20
sunscreen_fhe_program/src/lib.rs
View File

@@ -43,17 +43,17 @@ pub enum SchemeType {
* meanings onto these coefficients:
*
* * An integer x modulo p by setting the x^0 term to x and the remaining terms to 0 (i.e. scalar encoder).
* This encoding requires p be the desired maximum representable value. Overflow causes wrapping as
* one would expect. This encoding is generally inefficient.
* This encoding requires p be the desired maximum representable value. Overflow causes wrapping as
* one would expect. This encoding is generally inefficient.
* * An integer x decomposed into digits, where each digit is a coefficient in the plaintext polynomial.
* One may represent numbers larger than p with this technique. P should be chosen to accomodate the number
* of operations one wishes to perform so that no digit overflows under addition and multiplication. Overflow
* causes weird answers. Since this encoding typically allows for a smaller plaintext modulo, Sunscreen
* can choose parameters that result in low latency.
* One may represent numbers larger than p with this technique. P should be chosen to accomodate the number
* of operations one wishes to perform so that no digit overflows under addition and multiplication. Overflow
* causes weird answers. Since this encoding typically allows for a smaller plaintext modulo, Sunscreen
* can choose parameters that result in low latency.
* * A 2x(N/2) Batched vector of integers modulo p. Overflow wraps lane-wise, as expected. This encoding
* generally maximizes throughput when calulating many numbers. While the representation forms a matrix,
* multiplication and addition both execute element-wise; multiplication is *not* defined as matrix multiplation.
* This Batched computation is also referred to on the literature as batching.
* generally maximizes throughput when calulating many numbers. While the representation forms a matrix,
* multiplication and addition both execute element-wise; multiplication is *not* defined as matrix multiplation.
* This Batched computation is also referred to on the literature as batching.
*
* Each of these encoding schemes supports both signed and unsigned values.
*
@@ -86,7 +86,7 @@ pub enum SchemeType {
* Cons:
* * Bootstrapping not natively supported and isn't fast if one does implement it.
* * Some operations (e.g. comparison, division) are not easy to implement and any implementation
* will be approximate and/or particular to the scheme parameters.
* will be approximate and/or particular to the scheme parameters.
*/
Bfv,
}

12
sunscreen_math_macros/src/lib.rs
View File

@@ -57,13 +57,13 @@ fn emit_limbs(x: &BigInt, num_limbs: usize) -> TokenStream2 {
/// `#[barrett_config]` accepts `modulus`, `num_limbs`, and `is_field` as
/// arguments.
/// * `modulus` (required) - The modulus `q` defining the finite ring. This
/// must be a string literal containing either a decimal or hex number. Hex
/// values are prefixed with `0x`.
/// must be a string literal containing either a decimal or hex number. Hex
/// values are prefixed with `0x`.
/// * `num_limbs` (required) - The number of 64-bit bigint limbs desired to
/// represent Z_q.
/// represent Z_q.
/// * is_field (optional) - If `q` is prime, you may set this to true to
/// define `Z_q` as a field. This additionally allows you to compute
/// inverses.
/// define `Z_q` as a field. This additionally allows you to compute
/// inverses.
pub fn derive_barrett_config(input: proc_macro::TokenStream) -> TokenStream {
let input = parse_macro_input!(input);
let opts = Opts::from_derive_input(&input);
@@ -155,7 +155,7 @@ pub fn derive_barrett_config(input: proc_macro::TokenStream) -> TokenStream {
/// use std::ops::Add;
/// use sunscreen_math_macros::refify_binary_op;
///
/// pub trait WrappingSemantics:
/// pub trait WrappingSemantics:
/// Copy + Clone + std::fmt::Debug + WrappingAdd + WrappingMul + WrappingSub + WrappingNeg
/// {
/// }

10
sunscreen_tfhe/src/ops/bootstrapping/circuit_bootstrapping.rs
View File

@@ -59,15 +59,15 @@ use crate::{
///
/// # Panics
/// * If `bsk` is not valid for bootrapping from parameters `lwe_0` to `glwe_2`
/// (reinterpreted as LWE) with radix decomposition `pbs_radix`.
/// (reinterpreted as LWE) with radix decomposition `pbs_radix`.
/// * If `cbsksk` is not a valid keyswitch key set for switching from `glwe_2`
/// (reintrerpreted as LWE) to `glwe_1` with `glwe_1.dim.size` entries and radix
/// decomposition `pfks_radix`.
/// (reintrerpreted as LWE) to `glwe_1` with `glwe_1.dim.size` entries and radix
/// decomposition `pfks_radix`.
/// * If `output` is not the correct length for a GGSW ciphertext under `glwe_1`
/// parameters with `cbs_radix` decomposition.
/// parameters with `cbs_radix` decomposition.
/// * If `input` is not a valid LWE ciphertext under `lwe_0` parameters.
/// * If `lwe_0`, `glwe_1`, `glwe_2`, `cbs_radix`, `pfks_radix`, `pbs_radix` are
/// invalid.
/// invalid.
///
/// # Example
/// ```

2
sunscreen_tfhe/src/ops/ciphertext/lev_ciphertext_ops.rs
View File

@@ -11,7 +11,7 @@ use super::scalar_mul_ciphertext_mad;
/// * `b` is a LEV ciphertext.
/// * `c` is a LWE ciphertext.
/// * \[*\] is the external product between a LEV ciphertext and the decomposed
/// LWE ciphertext.
/// LWE ciphertext.
///
/// # Remarks
/// This functions takes a PolynomialRadixIterator to perform the decomposition.

4
sunscreen_tfhe/src/params.rs
View File

@@ -105,8 +105,8 @@ impl PrivateFunctionalKeyswitchLweCount {
/// * `count` must be greater than zero.
/// * `radix_log` must be greater than zero.
/// * `count * radix_log` must be less than equal to the number of bits in the
/// [`Torus`](crate::Torus) element used in the operation(s) performing radix
/// decomposition.
/// [`Torus`](crate::Torus) element used in the operation(s) performing radix
/// decomposition.
///
/// Calling [`assert_valid`](Self::assert_valid) will panic if the parameters are invalid.
pub struct RadixDecomposition {