circify / circ Goto Github PK

View Code? Open in Web Editor NEW

276.0 276.0 38.0 12.32 MB

(Cir)cuit (C)ompiler. Compiling high-level languages to circuits for SMT, zero-knowledge proofs, and more.

License: Other

Rust 95.34% Shell 2.14% Python 2.40% Dockerfile 0.03% Makefile 0.09%

circ's People

Contributors

Stargazers

Watchers

circ's Issues

OOB array access semantics

circ/src/ir/term/mod.rs

Lines 673 to 676 in a9fd788

 /// Select 

 pub fn select(&self, idx: &Value) -> Value { 

 self.map.get(idx).unwrap_or(&*self.default).clone() 

 }

@alex-ozdemir

IR OOB access semantics are "return the default for the array's value type", right? And if so, does this mean that if we want different semantics in a given language, the front-end needs to insert its own bounds checks?

(Or maybe I'm missing something obvious... again :) )

moduli and types for field elements

As @alex-ozdemir has noted elsewhere, one thing we eventually want to clean up is the way field elements are handled. This thread is intended to kick off a discussion of how we want to do that. Very brief background (I'm sure Alex can add a lot more info here):

Right now, we use rug::Integer values for field types. Unfortunately, they are not super fast for modular arithmetic, which is a problem we'd like to solve.

One thing we could do is fix a field-specific type in the IR at (CirC) compile time. That gives us speed, but not convenience. Note, however, that the Z# front-end fixes the modulus at compile time anyway, so it wouldn't materially change things convenience-wise to switch to field-specific types, at least for this front-end (but of course it would be much faster!).

A related option is to make the IR agnostic to field types, by writing down (or borrowing) traits that capture the functionality we need, and having the front-end decide what concrete type implements those traits. (I bet we could just use the ff traits for this, and in principle we could wrap rug::Integer values in a thin shim to get runtime modulus selection for front-ends that want it.) The negative way of looking at this is that it kicks the can to the front-end. The more positive way to look at it is that it gives front-ends the opportunity to optimize themselves for particular fields! I'd bet that in many cases the optimization is more important than runtime modulus flexibility...

One other option that's worth mentioning: we might look into how fast a modulus-flexible field library we could build, on the assumption that for a given value you wouldn't change the modulus very often. This would let us keep values in Montgomery form (almost) all the time, which gives a nice speed-up, but doesn't go all the way to requiring compile-time modulus selection. This option is compatible with the one directly above, in the sense that we could have this library implement the trait(s) that the IR requires and then plug this new library in (only?) when modulus flexibility is required.

Supporting smtlib output?

Hello, most sat/smt solvers like z3 use the smtlib format with sometimes extensions like the very efficient cryptominisat that support xor.

This would to use solver implementations running on fpga.

Excessive(?) RAM usage on moderately sized linear transforms

Compiling the following program to R1CS causes Circ to use over 10GB of RAM which at least to my undiscerning eye seems like it might be a bug.

const field[512][512] NTTMAT_512 = <elided for brevity>

def matmult<N,M>(field[N][M] A, field[M] v) -> field[N]:
    field[M] Av = [0; N]
    for u32 i in 0..N do
        for u32 j in 0.. M do
            Av[i] = Av[i] +  A[i][j] * v[j]
        endfor
    endfor
    return Av

def ntt(field[512] a) -> field[512]:
    return matmult(NTT512_MAT, a)

def check_equal<N>(field[N] a, field[N] b) -> bool:
    bool is_equal = true
    for u32 i in 0..N do
        is_equal = if (a[i] == b[i]) then is_equal else false fi
    endfor
    return is_equal

def main(field[512] a, field[512] a_ntt, field[512] b, field[512] b_ntt) -> bool:
    return check_equal(ntt(a), a_ntt) && check_equal(ntt(b), b_ntt)

I elided the 512 x 512 matrix above, but I've attached the file
here. Scaling this up to a 1024 x 1024 matrix causes Circ to use nearly 40GB of RAM.

If it helps, I have also attached a memory usage profile from running (unoptimized) CirC with DHAT (though I did SIGINT the process after 2 hours).

examples/C/r1cs/add.c apparently set up for MPC?

circ/examples/C/r1cs/add.c

Lines 1 to 6 in e362f95

 int mpc_main( 

 __attribute__((private(0))) int a, 

 __attribute__((private(1))) int b) 

 { 

 return a + b; 

 }

The mpc_main function here seems to imply that it's set up for MPC, but it's in the R1CS directory. @edwjchen is this expected or is this an error?

Errors in Setup/Proving/Verifying Phase

I tried to use CirC (the latest version #124) to compile some ZoKrates programs, but I saw some of the following errors.

Error 1: Compilation error when comparing two field elements
Error 2: Error in the proving phase of the program isolate_assert.zok
Error 3: Error in the verifying phase when there is an unused public input in the program

Error 1: Compilation error when comparing two field elements

Sample test code (testgreaterthan.zok):

def main(private field x, private field y) -> field:
    return if x > y then x  else y fi

Result:

$ ./target/release/examples/circ myexamples/testgreaterthan.zok r1cs --action setup
Options { path: "myexamples/testgreaterthan.zok", frontend: FrontendOptions { language: Auto, value_threshold: None, rec_limit: 5, lint_prim_rec: false, z_isolate_asserts: false }, parties: 2, backend: R1cs { prover_key: "P", verifier_key: "V", lc_elimination_thresh: 50, action: Setup } }
Done with IR optimization
Converting to r1cs
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/ubuntu/circlatest/circ/circ_fields/src/lib.rs:240:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Error 2: Error in the proving phase of the program isolate_assert.zok

Sample test code (isolate_assert.zok):

def mult(field x, field y) -> field:
    assert(x != y)
    return x * y

def main(private field x, private field y) -> field:
    return if x == y then x * x else mult(x, y) fi

Prover input (isolate_assert.zok.pin):

(set_default_modulus 52435875175126190479447740508185965837690552500527637822603658699938581184513
(let (
    (x #f4)
    (y #f4)
) true ;ignored
)
)

Result:

$ ./target/release/examples/circ examples/ZoKrates/pf/isolate_assert.zok r1cs --action setup
Options { path: "examples/ZoKrates/pf/isolate_assert.zok", frontend: FrontendOptions { language: Auto, value_threshold: None, rec_limit: 5, lint_prim_rec: false, z_isolate_asserts: false }, parties: 2, backend: R1cs { prover_key: "P", verifier_key: "V", lc_elimination_thresh: 50, action: Setup } }
Done with IR optimization
Converting to r1cs
Pre-opt R1cs size: 7
Final R1cs size: 3
Generating Parameters
$ ./target/release/examples/zk --inputs examples/ZoKrates/pf/isolate_assert.zok.pin --action prove
Proving
thread 'main' panicked at 'Error! Bad constraint:
    +0 is_zero_inv_n5 +1 (value #f0m52435875175126190479447740508185965837690552500527637822603658699938581184513)
  * +0 y_n1 -1 x_n2 +1 (value #f0m52435875175126190479447740508185965837690552500527637822603658699938581184513)
  = +1 (value #f1m52435875175126190479447740508185965837690552500527637822603658699938581184513)', src/target/r1cs/mod.rs:365:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Error 3: Error in the verifying phase when there is an unused public input in the program

Sample test code (unused_var.zok):

def main(u64 x0, u64 x1, u64 x2) -> u64:
    return x0 * x1

Prover Input (unused_var.zok.pin):

(let (
    (x0 #x0000000000000004)
    (x1 #x0000000000000004)
    (x2 #x0000000000000000)
)
    false
)

Verifier Input (unused_var.zok.vin):

(let (
    (x0 #x0000000000000004)
    (x1 #x0000000000000004)
    (x2 #x0000000000000000)
    (return #x0000000000000010)
)
    false
)

Result:

$ ./target/release/examples/circ myexamples/unused_var.zok r1cs --action setup
Options { path: "myexamples/unused_var.zok", frontend: FrontendOptions { language: Auto, value_threshold: None, rec_limit: 5, lint_prim_rec: false, z_isolate_asserts: false }, parties: 2, backend: R1cs { prover_key: "P", verifier_key: "V", lc_elimination_thresh: 50, action: Setup } }
Done with IR optimization
Converting to r1cs
Pre-opt R1cs size: 132
Final R1cs size: 131
Generating Parameters
$ ./target/release/examples/zk --inputs myexamples/unused_var.zok.pin --action prove
Proving
$ ./target/release/examples/zk --inputs myexamples/unused_var.zok.vin --action verify
Verifying
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: InvalidVerifyingKey', /home/ubuntu/circlatest/circ/src/target/r1cs/bellman.rs:331:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Thanks for your help!

Suggestions to make getting started a bit easier

I've just recently discovered this project and find it extremely interesting. Just a few observations after trying to get started:

From what I can tell, the circ example is the primary executable target. It's currently listed as an example, which forces the user to be inside this repository to use the compiler. What do you think about either moving it to src/main.rs or under [[bin]] ? It would bring things more in line with what other devs would expect.
Using the test file examples/C/r1cs/add.c, when running

cargo run --features="r1cs bellman c" --example circ add.c r1cs --action setup

I see the output

Done with IR optimization
Converting to r1cs
Pre-opt R1cs size: 1
Final R1cs size: 1
Generating Parameters

However, there is no compilation artifact left behind. I guess I'm not sure what I would expect to see, but at least some kind of file describing the r1cs. I think it would be helpful if the README gave a short quickstart for compiling an example program.

SetDefaultModulus bug

circ/src/ir/term/text/mod.rs

Lines 437 to 448 in 8bceb9a

 Err(CtrlOp::SetDefaultModulus) => { 

 assert_eq!( 

 tts.len(), 

 3, 

 "A set_default_modulus should have 2 arguments: modulus and term" 

 ); 

 let m = Arc::new(self.int(&tts[1])); 

 self.moduli.push(m); 

 let t = self.term(&tts[2]); 

 self.moduli.pop().unwrap(); 

 t 

 }

This code looks to be buggy. It pushes a new modulus and then immediately pops it, so on net nothing is added to moduli.

@alex-ozdemir I'm going to mess with this slightly in fixing something else, so no need to fix it---please just confirm that I'm not misunderstanding!

CI: clippy and format

I just ran cargo clippy and it looks like we have an enormous number of lints (almost 300), including some that are errors by default.

We should probably set up some crate-wide lint defaults (allow, deny, ...), clean up existing errors, and add clippy to the CI.

Ditto cargo format.

(and of course we shouldn't merge PRs that don't pass these minimal standards)

Brief licensing query

Hello! We've been taking a look at your paper and might be interested in contributing, if that's possible. Do you plan to license this project as OSS? I looked for a LICENSE file but didn't find one (though perhaps I missed it). Thanks!

in arch, "coinor-cbc" should be "coin-or-cbc"

circ/scripts/dependencies_arch.sh

Line 2 in df8dd66

pacman -S cvc4 coinor-cbc

At least, that's what it looks like to me...

Incorrect version of ZoKrates in README

circ/third_party/README.md

Lines 5 to 7 in 4686854

 ## Dependencies 

 * ZoKrates Parser & AST, version 0.6.3

In the README.md of third_party, the version of ZoKrates is 0.6.3, but according to #30, the version of ZoKrates has been updated to 0.7.6

compile C to R1CS

Hi, I'd like to try creating a SNARK for a C script (validating a certificate chain using mBedTLS).

I wanted to compile C---[circ]--> R1CS ---[libsnark]--> snark

Is this possible/practiable? How would do the circ step?

How to run on an example C program?

I want to generate an R1CS from an input C file -- how do I do that? Which utility do I need to run. Sorry for the vague question I can't seem to figure it out from the docs

How to print out the result

Hello, sorry for disturbing you.

I am trying to use the MPC part implemented in your code. I can run your script in circ/scripts/build_mpc_c_test.zsh. However, I want to print out the value to check, but I cannot find out a proper way to do it. I have tried printing by printf() in C, but it results in an error. May you help me with this?

reorg proposal: workspace, front- and back-ends in separate crates, etc.

Would it make sense to reorg the CirC codebase into a collection of smaller crates? It seems like, e.g., the ZoK/Z# front-end would be perfectly happy as its own crate.

The upside would be looser coupling among the front- and back-ends, which would encourage hygiene / discourage the kind of tight coupling that will ossify and make new front- and back-ends harder to write.

The downside is that, for now, the loose coupling may be an illusion---so this could take a lot of reorg effort.

I could start by pulling out Z# in the zsharp branch. It would be easiest if I converted the repo to a workspace at the same time. I don't think that should cause problems, but I may be wrong.

Compile C code to R1CS

Are there any instructions or examples that explain how to compile a C program into R1CS? I could find the add.c file in the examples/C/r1cs directory, but I don't know how to compile it.

How to compile circom to ꜱᴍᴛ ?

Simple question… Is it impossible because it can only compile to R1ᴄꜱ ?

with_indices: is this doing anything?

circ/src/front/zokrates/term.rs

Lines 187 to 193 in a9fd788

 let ir_term = term(Op::Tuple, { 

 let with_indices: BTreeMap<usize, Term> = ir_terms 

 .into_iter() 

 .map(|(name, t)| (field_ty_list.search(&name).unwrap().0, t)) 

 .collect(); 

 with_indices.into_iter().map(|(_i, t)| t).collect() 

 });

@alex-ozdemir quick question about the above: am I missing something here? It seems like with_indices gets computed as (index, value) tuples, and then the indices are immediately thrown away. Is there a reason to do this?

(I don't care about the efficiency, I'm just worried that either I'm missing something or there was supposed to be some other code here that is missing...)

performance issues: linearity reduction for R1CS

I've noticed some perf issues with linearity reduction, and Sebastian reported some in their application, too. @alex-ozdemir any chance this is a known issue? I haven't dug into it, but I should be starting to in the near future.

Unable to reproduce sha256/shaRound constraints number

According to Fig 19 of the CirC paper, the circuit size of sha256/shaRound in the ZoKrates standard library compiled by CirC should be 28949, but the circuit size I get with current version of CirC 4686854 is 33153

Commands I run

cargo build --release --features r1cs,smt,zok --example circ
./target/release/examples/circ ./third_party/ZoKrates/zokrates_stdlib/stdlib/hashes/sha256/shaRound.zok r1cs

Log I get

Options { path: "./third_party/ZoKrates/zokrates_stdlib/stdlib/hashes/sha256/shaRound.zok", frontend: FrontendOptions { language: Auto, value_threshold: None, rec_limit: 5, lint_prim_rec: false, z_isolate_asserts: false }, parties: 2, backend: R1cs { prover_key: "P", verifier_key: "V", lc_elimination_thresh: 50, action: Count } }
Done with IR optimization
Converting to r1cs
Pre-opt R1cs size: 52244
Final R1cs size: 33153

How can I reduce the circuit size of shaRound in current version of CirC?

IR tuple internal repr

circ/src/ir/term/mod.rs

Lines 625 to 626 in 11242a6

 /// Tuple 

 Tuple(Vec<Value>),

This is a small thing, but: would it make sense for this to be Tuple(Box<[Value]>) instead? The advantage is that this guarantees it cannot be grown or shrunk after creation, which makes sense for a Tuple (I think).

cfold: divide by zero semantics

circ/src/ir/opt/cfold.rs

Lines 104 to 107 in c784bf7

 (Udiv, _, Some(b)) if b.uint() == &Integer::from(0) => Some(bv_lit( 

 (Integer::from(1) << b.width() as u32) - 1, 

 b.width(), 

 )),

Unless I'm missing something, the divide-by-zero semantics here are to return uint-max for the given bit width. That seems wrong. Shouldn't this just panic?

Cannot perform op `==` on array and array

def main(u32[8] a):

	assert(a == [0; 8])
	return

Circ returns the following error message:

Options { zokrates_path: "test.zok", inputs: None, parties: None }
Error: Cannot perform op '==' on array and array
In: test.zok
  	assert(a == [0; 8])

Would it be possible to support == on arrays? This feature is available in ZoKrates 0.6.3.

optimization opportunity: constants in operations whose cost depends on operand size

For operations like x < 42, where the cost of the operation depends on operand size and one of the operands is known at compile time, it should be possible to optimize the output for some back-ends (R1CS, arithmetic and boolean ckts, ...). Would be great to add this!

A few unknowns (to me) right now:

does this require propagating more info to the back-end lowering process?
is there some general way of doing this, or will each operation need its own notion of constant-optimization?
where is the right place to do this?

Not a high priority thing, but would be nice...

Upgrading ZoKrates to 0.7.x. Support for const and u64.

ZoKrates 0.7.1 and above seems to have introduced new features (const, u64) and gadgets ( keccak, sha3).
It would be great to have access to those features through CirC!
Would it be possible to upgrade ZoKrates from 0.6.3 to 0.7.5?

compile error

I am trying to compile 76539bf / master on x86_64 GNU/Linux

I am using Nix for dependencies.
I use the exact shell.nix shown in the "Installation via rustup" section of the nix wiki, except I added

      boost
      cbc
      cmake
      gmp

to buildInputs.

I get the follow compile error.
The error is at the bottom of this output.
I am including the entire make output for completeness.

[nix-shell:~/github-circify-circ-rust]$ make 
cargo build --release --examples
    Finished release [optimized + debuginfo] target(s) in 1.19s
cargo build --examples
    Finished dev [unoptimized + debuginfo] target(s) in 0.84s
git submodule update --init
./scripts/build_aby.zsh
ENCRYPTO_utils was not found: add ENCRYPTO_utils subdirectory
-- Found Boost: /nix/store/fw8hklwqxngimxyz2rbg0vskq911pj5c-boost-1.77.0-dev/lib/cmake/Boost-1.77.0/BoostConfig.cmake (found suitable version "1.77.0", minimum required is "1.66.0") found components: system thread 
RELIC was not found: add RELIC subdirectory
CMake Warning (dev) at extern/ENCRYPTO_utils/CMakeLists.txt:40 (set):
  implicitly converting 'INTEGER' to 'STRING' type.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at extern/ENCRYPTO_utils/CMakeLists.txt:42 (set):
  implicitly converting 'BOOl' to 'STRING' type.
This warning is for project developers.  Use -Wno-dev to suppress it.


-- Configuring RELIC 0.5.0...

-- Available switches (default = CHECK, VERBS, DOCUM):

   DEBUG=[off|on] Build with debugging support.
   PROFL=[off|on] Build with profiling support.
   CHECK=[off|on] Build with error-checking support.
   VERBS=[off|on] Build with detailed error messages.
   OVERH=[off|on] Build with overhead estimation.
   DOCUM=[off|on] Build documentation.
   STRIP=[off|on] Build only selected algorithms.
   QUIET=[off|on] Build with printing disabled.
   COLOR=[off|on] Build with colored output.
   BIGED=[off|on] Build with big-endian support.
   SHLIB=[off|on] Build shared library.
   STLIB=[off|on] Build static library.
   STBIN=[off|on] Build static binaries.
   AMALG=[off|on] Build amalgamation for better performance.
   AUSAN=[off|on] Build with ASan and UBSan (gcc/clang only).

-- Number of times each test or benchmark is ran (default = 50, 1000):

   TESTS=n        If n > 0, build automated tests and run them n times.
   BENCH=n        If n > 0, build automated benchmarks and run them n * n times.

-- Number of available processor cores (default = 1):

   CORES=n        If n > 1, enable multithreading support.

-- Available modules (default = ALL)

   WITH=BN       Multiple precision arithmetic.
   WITH=DV       Temporary double-precision digit vectors.
   WITH=FP       Prime field arithmetic.
   WITH=FPX      Prime extension field arithmetic.
   WITH=FB       Binary field arithmetic.
   WITH=EP       Elliptic curves over prime fields.
   WITH=EPX      Elliptic curves over quadratic extensions of prime fields.
   WITH=EB       Elliptic curves over binary fields.
   WITH=ED       Elliptic Edwards curves over prime fields.
   WTTH=EC       Elliptic curve cryptography.
   WITH=PB       Pairings over binary elliptic curves.
   WITH=PP       Pairings over prime elliptic curves.
   WTTH=PC       Pairing-based cryptography.
   WITH=BC       Block ciphers (symmetric encryption).
   WITH=MD       Message digests (hash functions).
   WITH=CP       Cryptographic protocols.
   WITH=MPC      Multi-party computation primitives.
   WITH=ALL      All of the above.
   Note: the programmer is responsible for not using unselected modules.

-- Available arithmetic backends (default = easy):

   ARITH=easy     Easy-to-understand and portable, but slow backend.
   ARITH=fiat     Backend based on code generated from Fiat-Crypto.
   ARITH=gmp      Backend based on GNU Multiple Precision library.

   ARITH=gmp-sec  Same as above, but using constant-time code.

-- Available memory-allocation policies (default = AUTO):

   ALLOC=AUTO     All memory is automatically allocated.
   ALLOC=DYNAMIC  All memory is allocated dynamically on demand.

-- Supported operating systems (default = LINUX):

   OPSYS=         Undefined/No specific operating system.
   OPSYS=LINUX    GNU/Linux operating system.
   OPSYS=FREEBSD  FreeBSD operating system.
   OPSYS=NETBSD   NetBSD operating system.
   OPSYS=MACOSX   Mac OS X operating system.
   OPSYS=WINDOWS  Windows operating system.
   OPSYS=DROID    Android operating system.
   OPSYS=DUINO    Arduino platform.

-- Supported multithreading APIs (default = UNDEF):

   MULTI=         No multithreading support.
   MULTI=OPENMP   Open Multi-Processing.
   MULTI=PTHREAD  POSIX threads.

-- Supported timers (default = HREAL):

   TIMER=         No timer.
   TIMER=HREAL    GNU/Linux realtime high-resolution timer.
   TIMER=HPROC    GNU/Linux per-process high-resolution timer.
   TIMER=HTHRD    GNU/Linux per-thread high-resolution timer.
   TIMER=ANSI     ANSI-compatible timer.
   TIMER=POSIX    POSIX-compatible timer.
   TIMER=CYCLE    Cycle-counting timer. (architecture-dependant)
   TIMER=PERF     GNU/Linux performance monitoring framework.

-- Prefix to identify this build of the library (default = ""):

   LABEL=relic

-- Available architectures (default = X64):

   ARCH=          No specific architecture (disable some features).
   ARCH=AVR       Atmel AVR ATMega128 8-bit architecture.
   ARCH=MSP       TI MSP430 16-bit architecture.
   ARCH=ARM       ARM 32-bit architecture.
   ARCH=X86       Intel x86-compatible 32-bit architecture.
   ARCH=X64       AMD x86_64-compatible 64-bit architecture.

-- Available word sizes (default = 64):

   WSIZE=8        Build a 8-bit library.
   WSIZE=16       Build a 16-bit library.
   WSIZE=32       Build a 32-bit library.
   WSIZE=64       Build a 64-bit library.

-- Byte boundary to align digit vectors (default = 1):

   ALIGN=1        Do not align digit vectors.
   ALIGN=2        Align digit vectors into 16-bit boundaries.
   ALIGN=8        Align digit vectors into 64-bit boundaries.
   ALIGN=16       Align digit vectors into 128-bit boundaries.

-- Multiple precision arithmetic configuration (BN module):

   ** Options for the multiple precision module (default = 1024,DOUBLE,0):

      BN_PRECI=n        The base precision in bits. Let w be n in words.
      BN_MAGNI=DOUBLE   A multiple precision integer can store 2w words.
      BN_MAGNI=CARRY    A multiple precision integer can store w+1 words.
      BN_MAGNI=SINGLE   A multiple precision integer can store w words.
      BN_KARAT=n        The number of Karatsuba steps.

   ** Available multiple precision arithmetic methods (default = COMBA;COMBA;MONTY;SLIDE;BASIC;BASIC):

      Integer multiplication:
      BN_METHD=BASIC    Schoolbook multiplication.
      BN_METHD=COMBA    Comba multiplication.

      Integer squaring:
      BN_METHD=BASIC    Schoolbook squaring.
      BN_METHD=COMBA    Comba squaring.
      BN_METHD=MULTP    Reuse multiplication for squaring.

      Modular reduction:
      BN_METHD=BASIC    Division-based modular reduction.
      BN_METHD=BARRT    Barrett modular reduction.
      BN_METHD=MONTY    Montgomery modular reduction.
      BN_METHD=RADIX    Diminished radix modular reduction.

      Modular exponentiation:
      BN_METHD=BASIC    Binary modular exponentiation.
      BN_METHD=MONTY    Montgomery powering ladder.
      BN_METHD=SLIDE    Sliding window modular exponentiation.

      Greatest Common Divisor:
      BN_METHD=BASIC    Euclid's standard GCD algorithm.
      BN_METHD=LEHME    Lehmer's fast GCD algorithm.
      BN_METHD=STEIN    Stein's binary GCD algorithm.

      Prime generation:
      BN_METHD=BASIC    Basic prime generation.
      BN_METHD=SAFEP    Safe prime generation.
      BN_METHD=STRON    Strong prime generation.

-- Prime field arithmetic configuration (FP module):

   ** Arithmetic precision of the prime field module (default = 256,0,off,off):

      FP_PRIME=n        The prime modulus size in bits.
      FP_KARAT=n        The number of Karatsuba levels.
      FP_PMERS=[off|on] Prefer Pseudo-Mersenne primes over random primes.
      FP_QNRES=[off|on] Use -1 as quadratic non-residue (make sure that p = 3 mod 8).
      FP_WIDTH=w        Width w in [2,6] of window processing for exponentiation methods.

   ** Available prime field arithmetic methods (default = BASIC;COMBA;COMBA;MONTY;MONTY;SLIDE):
      Field addition
      FP_METHD=BASIC    Schoolbook addition.
      FP_METHD=INTEG    Integrated modular addition.

      Field multiplication
      FP_METHD=BASIC    Schoolbook multiplication.
      FP_METHD=INTEG    Integrated modular multiplication.
      FP_METHD=COMBA    Comba multiplication.

      Field squaring
      FP_METHD=BASIC    Schoolbook squaring.
      FP_METHD=INTEG    Integrated modular squaring.
      FP_METHD=COMBA    Comba squaring.
      FP_METHD=MULTP    Reuse multiplication for squaring.

      Modular reduction
      FP_METHD=BASIC    Division-based reduction.
      FP_METHD=QUICK    Fast reduction modulo special form prime (2^t - c, c > 0).
      FP_METHD=MONTY    Montgomery modular reduction.

      Field inversion
      FP_METHD=BASIC    Inversion by Fermat's Little Theorem.
      FP_METHD=BINAR    Binary Inversion algorithm.
      FP_METHD=MONTY    Montgomery inversion.
      FP_METHD=EXGCD    Inversion by the Extended Euclidean algorithm.
      FP_METHD=DIVST    Constant-time inversion by division steps.
      FP_METHD=LOWER    Pass inversion to the lower level.

      Field exponentiation
      FP_METHD=BASIC    Binary exponentiation.
      FP_METHD=SLIDE    Sliding window exponentiation.
      FP_METHD=MONTY    Constant-time Montgomery powering ladder.

-- Prime extension field arithmetic configuration (FPX module):

   ** Available bilinear pairing methods (default = BASIC;BASIC;BASIC):
      Quadratic extension arithmetic:
      FPX_METHD=BASIC    Basic quadratic extension field arithmetic.
      FPX_METHD=INTEG    Quadratic extension field arithmetic with embedded modular reduction.

      Cubic extension arithmetic:
      FPX_METHD=BASIC    Basic cubic extension field arithmetic.
      FPX_METHD=INTEG    Cubic extension field arithmetic with embedded modular reduction.

      Extension field arithmetic:
      FPX_METHD=BASIC    Basic extension field arithmetic.
      FPX_METHD=LAZYR    Lazy-reduced extension field arithmetic.

-- Binary field arithmetic configuration (FB module):

   ** Options for the binary elliptic curve module (default = 283,0,on,on,on):

      FB_POLYN=n        The irreducible polynomial size in bits.
      FB_KARAT=n        The number of Karatsuba levels.
      FB_TRINO=[off|on] Prefer trinomials.
      FB_SQRTF=[off|on] Prefer square-root friendly polynomials.
      FB_PRECO=[off|on] Precompute multiplication table for sqrt(z).
      FB_WIDTH=w        Width w in [2,6] of window processing for exponentiation methods.

   ** Available binary field arithmetic methods (default = LODAH;QUICK;QUICK;BASIC;QUICK;QUICK;EXGCD;SLIDE;QUICK):

      Field multiplication:
      FB_METHD=BASIC    Right-to-left shift-and-add multiplication.
      FB_METHD=INTEG    Integrated modular multiplication.
      FB_METHD=LODAH    L�pez-Dahab comb multiplication with window of width 4.

      Field squaring:
      FB_METHD=BASIC    Bit manipulation squaring.
      FB_METHD=INTEG    Integrated modular squaring.
      FB_METHD=QUICK    Table-based squaring.

      Modular reduction:
      FB_METHD=BASIC    Shift-and-add modular reduction.
      FB_METHD=QUICK    Fast reduction modulo a trinomial or pentanomial.

      Field square root:
      FB_METHD=BASIC    Square root by repeated squaring.
      FB_METHD=QUICK    Fast square root extraction.

      Trace computation:
      FB_METHD=BASIC    Trace computation by repeated squaring.
      FB_METHD=QUICK    Fast trace computation.

      Quadratic equation solver:
      FB_METHD=BASIC    Solve a quadratic equation by half-trace computation.
      FB_METHD=QUICK    Fast solving with precomputed half-traces.

      Field inversion:
      FB_METHD=BASIC    Inversion by Fermat's Little Theorem.
      FB_METHD=BINAR    Binary Inversion algorithm.
      FB_METHD=ALMOS    Inversion by the Amost inverse algorithm.
      FB_METHD=EXGCD    Inversion by the Extended Euclidean algorithm.
      FB_METHD=ITOHT    Inversion by Itoh-Tsuji.
      FB_METHD=CTAIA    Constant-time almost inversion algorithm.
      FB_METHD=BRUCH    Hardware-friendly inversion by Brunner et al.
      FB_METHD=LOWER    Pass inversion to the lower level.

      Field exponentiation:
      FB_METHD=BASIC    Binary exponentiation.
      FB_METHD=SLIDE    Sliding window exponentiation.
      FB_METHD=MONTY    Constant-time Montgomery powering ladder.

      Iterated squaring/square-root:
      FB_METHD=BASIC    Iterated squaring/square-root by consecutive squaring/square-root.
      FB_METHD=QUICK    Iterated squaring/square-root by table-based method.

-- Prime elliptic curve arithmetic configuration (EP module):

   ** Options for the prime elliptic curve module (default = all on):

      EP_PLAIN=[off|on] Support for ordinary curves without endomorphisms.
      EP_SUPER=[off|on] Support for supersingular curves.
      EP_ENDOM=[off|on] Support for ordinary curves with endomorphisms.
      EP_MIXED=[off|on] Use mixed coordinates.
      EP_CTMAP=[off|on] Use contant-time SSWU and isogeny map for hashing.

      EP_PRECO=[off|on] Build precomputation table for generator.
      EP_DEPTH=w        Width w in [2,8] of precomputation table for fixed point methods.
      EP_WIDTH=w        Width w in [2,6] of window processing for unknown point methods.

   ** Available prime elliptic curve methods (default = PROJC;LWNAF;COMBS;INTER):

      Point representation:
      EP_METHD=BASIC    Affine coordinates.
      EP_METHD=PROJC    Homogeneous projective coordinates (complete formula).
      EP_METHD=JACOB    Jacobian projective coordinates.

      Variable-base scalar multiplication:
      EP_METHD=BASIC    Binary method.
      EP_METHD=LWNAF    Left-to-right window NAF method (GLV for Koblitz curves).

      Fixed-base scalar multiplication:
      EP_METHD=BASIC    Binary method for fixed point multiplication.
      EP_METHD=COMBS    Single-table Comb method for fixed point multiplication.
      EP_METHD=COMBD    Double-table Comb method for fixed point multiplication.
      EP_METHD=LWNAF    Left-to-right window NAF method (GLV for curves with endomorphisms).
      EP_METHD=LWREG    Left-to-right regular recoding method (GLV for curves with endomorphisms).

      Variable-base simultaneous scalar multiplication:
      EP_METHD=BASIC    Multiplication-and-addition simultaneous multiplication.
      EP_METHD=TRICK    Shamir's trick for simultaneous multiplication.
      EP_METHD=INTER    Interleaving of window NAFs (GLV for Koblitz curves).
      EP_METHD=JOINT    Joint sparse form.

-- Binary elliptic curve arithmetic configuration (EB module):

   ** Options for the binary elliptic curve module (default = on, w = 4):

      EB_PLAIN=[off|on] Support for ordinary curves without endomorphisms.
      EB_KBLTZ=[off|on] Support for Koblitz anomalous binary curves.
      EB_MIXED=[off|on] Use mixed coordinates.
      EB_PRECO=[off|on] Build precomputation table for generator.
      EB_DEPTH=w        Width w in [2,8] of precomputation table for fixed point methods.
      EB_WIDTH=w        Width w in [2,6] of window processing for unknown point methods.

   ** Available binary elliptic curve methods (default = PROJC;LWNAF;COMBS;INTER):

      Point representation:
      EB_METHD=BASIC    Affine coordinates.
      EB_METHD=PROJC    Projective coordinates (L�pez-Dahab for ordinary curves).

      Variable-base scalar multiplication:
      EB_METHD=BASIC    Binary double-and-add method.
      EB_METHD=LODAH    Lopez-Dahab constant-time point multiplication.
      EB_METHD=LWNAF    Left-to-right window (T)NAF method.
      EB_METHD=RWNAF    Right-to-left window (T)NAF method.
      EB_METHD=HALVE    Halving method.

      Fixed-base scalar multiplication:
      EB_METHD=BASIC    Binary method for fixed point multiplication.
      EB_METHD=COMBS    Single-table Comb method for fixed point multiplication.
      EB_METHD=COMBD    Double-table Comb method for fixed point multiplication.
      EB_METHD=LWNAF    Left-to-right window (T)NAF method.

      Variable-base simultaneous scalar multiplication:
      EB_METHD=BASIC    Multiplication-and-addition simultaneous multiplication.
      EB_METHD=TRICK    Shamir's trick for simultaneous multiplication.
      EB_METHD=INTER    Interleaving of window (T)NAFs.
      EB_METHD=JOINT    Joint sparse form.

-- Elliptic Edwards curve over prime fields arithmetic configuration (ED module):

   ** Options for the prime elliptic Edwards curve module (default = all on):
      ED_PRECO=[off|on] Build precomputation table for generator.
      ED_DEPTH=w        Width w in [2,6] of precomputation table for fixed point methods.
      ED_WIDTH=w        Width w in [2,6] of window processing for unknown point methods.

   ** Available prime elliptic Edwards curve methods (default = PROJC;LWNAF;COMBS;INTER):
      ED_METHD=BASIC    Affine coordinates.
      EP_METHD=PROJC  	 Simple projective twisted Edwards coordinates.
      EP_METHD=EXTND 	 Extended projective twisted Edwards coordinates.

      *** variable-base multiplication method ***
      ED_METHD=BASIC    Binary method.
      ED_METHD=SLIDE    Sliding window method.
      ED_METHD=MONTY    Montgomery ladder method.
      ED_METHD=LWNAF    Left-to-right window NAF method.
      EP_METHD=LWREG    Left-to-right regular recoding method (GLV for curves with endomorphisms).

      *** fixed-base multiplication method ***
      ED_METHD=BASIC    Binary method for fixed point multiplication.
      ED_METHD=COMBS    Single-table Comb method for fixed point multiplication.
      ED_METHD=COMBD    Double-table Comb method for fixed point multiplication.
      ED_METHD=LWNAF    Left-to-right window NAF method.

      *** variable-base simultaneous multiplication method ***
      ED_METHD=BASIC    Multiplication-and-addition simultaneous multiplication.
      ED_METHD=TRICK    Shamir's trick for simultaneous multiplication.
      ED_METHD=INTER    Interleaving of window NAFs (GLV for Koblitz curves).
      ED_METHD=JOINT    Joint sparse form.

      Note: these methods must be given in order. Ex: ED_METHD="EXTND;LWNAF;COMBD;TRICK"

-- Elliptic curve cryptography configuration (EC module):

   ** Options for the binary elliptic curve module (default = on):

      EC_ENDOM=[off|on] Prefer (prime or binary) curves with endomorphisms.

   ** Available elliptic curve methods (default = PRIME):

      EC_METHD=PRIME    Use prime curves.
      EC_METHD=CHAR2    Use binary curves.
      EC_METHD=EDDIE    Use prime Edwards curves.

-- Bilinear pairings arithmetic configuration (PP module):

   ** Available bilinear pairing methods (default = BASIC;OATEP):

      Extension field arithmetic:
      PP_METHD=BASIC    Basic extension field arithmetic.
      PP_METHD=LAZYR    Lazy reduced extension field arithmetic.

      Pairing computation:
      PP_METHD=TATEP    Tate pairing.
      PP_METHD=WEILP    Weil pairing.
      PP_METHD=OATEP    Optimal ate pairing.

-- Message digest configuration (MD module):

   ** Available hash functions (default = SH256):

      MD_METHD=SH224        SHA-224 hash function.
      MD_METHD=SH256        SHA-256 hash function.
      MD_METHD=SH384        SHA-384 hash function.
      MD_METHD=SH512        SHA-512 hash function.
      MD_METHD=B2S160       BLAKE2s-160 hash function.
      MD_METHD=B2S256       BLAKE2s-256 hash function.

-- Cryptographic protocols configuration (CP module):

   ** Options for the cryptographic protocols module (default = on, PKCS2):

      CP_CRT=[off|on] Support for faster CRT-based exponentiation in factoring-based cryptosystems.

      CP_RSAPD=BASIC    RSA with basic padding.
      CP_RSAPD=PKCS1    RSA with PKCS#1 v1.5 padding.
      CP_RSAPD=PKCS2    RSA with PKCS#1 v2.1 padding.

-- Available pseudo-random number generators (default = HASHD):

   RAND=HASHD     Use the HASH-DRBG generator. (recommended)
   RAND=RDRND     Use Intel RdRand instruction directly.
   RAND=UDEV      Use the operating system underlying generator.
   RAND=CALL      Override the generator with a callback.

-- Available random number generator seeders (default = UDEV):

   SEED=          Use a zero seed. (horribly insecure!)
   SEED=LIBC      Use rand()/random() functions. (insecure!)
   SEED=RDRND     Use Intel RdRand instruction directly.
   SEED=UDEV      Use non-blocking /dev/urandom. (recommended)
   SEED=WCGR      Use Windows' CryptGenRandom. (recommended)

-- Configured operating system: LINUX
-- Compiler flags:  -Wall   -O3 -funroll-loops -fomit-frame-pointer -march=core2 -msse4.2 -mpclmul
-- Linker flags: -L/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/extern/ENCRYPTO_utils/extern/relic/src/low/curve2251-sse/ 
-- Configured /home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/extern/ENCRYPTO_utils/extern/relic/include/relic_conf.h.in
-- Configured GMP: -I/nix/store/ryschvm8md9iswan8g0azdgaxpqqs4m5-gmp-6.2.1-dev/include -L/nix/store/cvffg9qx4m3kl4f093x6mqvqdvah4sx1-gmp-6.2.1/lib/libgmp.so
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
OTExtension was not found: add OTExtension subdirectory
-- Found Boost: /nix/store/fw8hklwqxngimxyz2rbg0vskq911pj5c-boost-1.77.0-dev/lib/cmake/Boost-1.77.0/BoostConfig.cmake (found suitable version "1.77.0", minimum required is "1.66.0") found components: thread system 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build
make[1]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[2]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[3]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[3]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
[  0%] Built target arith_objs
make[3]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
Consolidate compiler generated dependencies of target relic_s
make[3]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
[ 44%] Built target relic_s
make[3]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
Consolidate compiler generated dependencies of target encrypto_utils
make[3]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[3]: Entering directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
[ 44%] Building CXX object extern/ENCRYPTO_utils/src/CMakeFiles/encrypto_utils.dir/ENCRYPTO_utils/cbitvector.cpp.o
In file included from /home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/extern/ENCRYPTO_utils/src/ENCRYPTO_utils/crypto/crypto.h:24,
                 from /home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/extern/ENCRYPTO_utils/src/ENCRYPTO_utils/cbitvector.cpp:20:
/nix/store/2dv93bbc06c7zg866qid73j3r36zz3jx-gcc-10.3.0/include/c++/10.3.0/mutex: In member function 'bool std::timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)':
/nix/store/2dv93bbc06c7zg866qid73j3r36zz3jx-gcc-10.3.0/include/c++/10.3.0/mutex:270:17: error: 'pthread_mutex_clocklock' was not declared in this scope; did you mean 'pthread_mutex_unlock'?
  270 |       { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }
      |                 ^~~~~~~~~~~~~~~~~~~~~~~
      |                 pthread_mutex_unlock
/nix/store/2dv93bbc06c7zg866qid73j3r36zz3jx-gcc-10.3.0/include/c++/10.3.0/mutex: In member function 'bool std::recursive_timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)':
/nix/store/2dv93bbc06c7zg866qid73j3r36zz3jx-gcc-10.3.0/include/c++/10.3.0/mutex:336:17: error: 'pthread_mutex_clocklock' was not declared in this scope; did you mean 'pthread_mutex_unlock'?
  336 |       { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }
      |                 ^~~~~~~~~~~~~~~~~~~~~~~
      |                 pthread_mutex_unlock
make[3]: *** [extern/ENCRYPTO_utils/src/CMakeFiles/encrypto_utils.dir/build.make:76: extern/ENCRYPTO_utils/src/CMakeFiles/encrypto_utils.dir/ENCRYPTO_utils/cbitvector.cpp.o] Error 1
make[3]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[2]: *** [CMakeFiles/Makefile2:520: extern/ENCRYPTO_utils/src/CMakeFiles/encrypto_utils.dir/all] Error 2
make[2]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make[1]: *** [Makefile:136: all] Error 2
make[1]: Leaving directory '/home/hcarr/ws/OLABS/github-circify-circ-rust/third_party/ABY/build'
make: *** [Makefile:7: build_deps] Error 2

[nix-shell:~/github-circify-circ-rust]$

I am wondering if this is a real error or if it is due to using nix or something else?

Circom intermediate representation

Hello,
I have encountered this project while searching for mutation testing tools for circom.

From my initial research, such a tool does not exist, so I am motivated to create an initial proof of concept to improve the test coverage of some codebases I am reviewing.

Mutating the code and analyzing how the tests behave is the easy part, but before that, I need to properly parse the circuits. I would like to know if I can use circify for that, and if so, if there is any documentation explaining how to do it.

Thanks

PfToBv: only defined for field elms in 0,1?

circ/src/ir/term/mod.rs

Lines 1335 to 1339 in 0d61d45

 Op::PfToBv(w) => Value::BitVector({ 

 let a = vs.get(&c.cs[0]).unwrap().as_pf().clone(); 

 assert!(a.i() < &(Integer::from(1) << 1)); 

 BitVector::new(a.i().clone(), *w) 

 }),

Am I reading this correctly? Is this assert necessary?

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow

An Open Source Machine Learning Framework for Everyone
Django

The Web framework for perfectionists with deadlines.
Laravel

A PHP framework for web artisans
D3

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web

Some thing interesting about web. New door for the world.
server

A server is a program made to process requests and deliver data to clients.
Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization

Some thing interesting about visualization, use data art
Game

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft

Open source projects and samples from Microsoft.
Google

Google ❤️ Open Source for everyone.
Alibaba

Alibaba Open Source for everyone
D3

Data-Driven Documents codes.
Tencent

China tencent open source team.

Jobs

Jooble

	/// Select
	pub fn select(&self, idx: &Value) -> Value {
	self.map.get(idx).unwrap_or(&*self.default).clone()
	}

	int mpc_main(
	__attribute__((private(0))) int a,
	__attribute__((private(1))) int b)
	{
	return a + b;
	}

	Err(CtrlOp::SetDefaultModulus) => {
	assert_eq!(
	tts.len(),
	3,
	"A set_default_modulus should have 2 arguments: modulus and term"
	);
	let m = Arc::new(self.int(&tts[1]));
	self.moduli.push(m);
	let t = self.term(&tts[2]);
	self.moduli.pop().unwrap();
	t
	}

	let ir_term = term(Op::Tuple, {
	let with_indices: BTreeMap<usize, Term> = ir_terms
	.into_iter()
	.map(\|(name, t)\| (field_ty_list.search(&name).unwrap().0, t))
	.collect();
	with_indices.into_iter().map(\|(_i, t)\| t).collect()
	});

	(Udiv, _, Some(b)) if b.uint() == &Integer::from(0) => Some(bv_lit(
	(Integer::from(1) << b.width() as u32) - 1,
	b.width(),
	)),

	Op::PfToBv(w) => Value::BitVector({
	let a = vs.get(&c.cs[0]).unwrap().as_pf().clone();
	assert!(a.i() < &(Integer::from(1) << 1));
	BitVector::new(a.i().clone(), *w)
	}),

circify / circ Goto Github PK

circ's People

Contributors

Stargazers

Watchers

Forkers

circ's Issues

Error 1: Compilation error when comparing two field elements

Error 2: Error in the proving phase of the program isolate_assert.zok

Error 3: Error in the verifying phase when there is an unused public input in the program

Recommend Projects

Recommend Topics

Recommend Org

Jobs