If I am not mistaken, the constructor of https://github.com/emp-toolkit/emp-tool/blob/stable/emp-tool/utils/prg.h is not thread safe when seed=nullptr, because of the fields counter and rnd. Do you plan to write a thread safe version?

The simplest workaround might be to add a boolean parameter thread_safe to the constructor. When thread_safe is true, the constructor does not set nor use rnd, and seed the PRG with std::random_device.

What do you think?

This is important for large circuits.

The function uni_hash_coeff_gen only works when sz is large enough because it may access the array beyond the sz bound.
https://github.com/emp-toolkit/emp-tool/blob/master/emp-tool/utils/f2k.h#L114

inline void uni_hash_coeff_gen(block* coeff, block seed, int sz) {
	coeff[0] = seed;
	gfmul(seed, seed, &coeff[1]);
	gfmul(coeff[1], seed, &coeff[2]);
	block multiplier;
	gfmul(coeff[2], seed, &multiplier);
	coeff[3] = multiplier;
	int i = 4;
	for(; i < sz-3; i+=4) {
		gfmul(coeff[i-4], multiplier, &coeff[i]);
		gfmul(coeff[i-3], multiplier, &coeff[i+1]);
		gfmul(coeff[i-2], multiplier, &coeff[i+2]);
		gfmul(coeff[i-1], multiplier, &coeff[i+3]);
	}
	int remainder = sz%4;
	if(remainder != 0) {
		i = sz - remainder;
		for(; i < sz; ++i)
			gfmul(coeff[i-1], seed, &coeff[i]);
	}
}

Importantly, its behavior becomes very unstable if sz = 1, where

gfmul(coeff[i-1], seed, &coeff[i]);

becomes

gfmul(coeff[-1], seed, &coeff[0]);

such that the first element (aka chi[0]) is touching dirty memory data.

The #define HALFGATE_GEN_H__ line in file emp-tool/gc/circuit_file_generator.h seems not necessary.

Hi,

Really nice to e-meet you!

Recently, I am trying to use EMP-TOOLKIT to generate some bristol format circuits and evaluate these circuits in EMP-MPC. However, my test shows that the EMP-MPC outputs are incorrect and I suddenly realize that it is caused by my wrong way to set input wire values. For example,

First, I generate a simply two (in my real application, there will be more) millionaires problem circuit (both inputs known by Alice) as follow:

using Circuit = emp::BristolFormat;
{
    emp::setup_plain_prot(true, FILENAME);
    emp::Integer a {2, 0, emp::ALICE};
    emp::Integer b {2, 0, emp::ALICE};
    emp::Bit cond1 = (b > a);
    cond1.reveal<bool>();
    emp::finalize_plain_prot();
}

Then I evaluate the output circuit in EMP-MPC to get the truth table and my evaluation shows that:

• a = in[3]*2 + in[0]
• b = in[1]*2 + in[2]

where in[0..3] are four input wires, which is different from what I thought it would be as:

• a = in[3]*2 + in[2]
• b = in[1]*2 + in[0]

or somthing similar to this.

Therefore, I am wondering if there is an efficient way for me to generate the circuit in EMP-TOOLKIT so I can know the way to parse wires to corresponding emp::Integer. Or if I can output something while generating the circuits to explicitly show this relationship.

Thank you very much!

When I was compiling this library, It shows many warnings. But it can build successfuly.

Now I report to you and hope you can solve it.

`locomotive@locomotive-VirtualBox:~/emp/emp-tool-master/build$ make

Scanning dependencies of target emp-tool

[ 3%] Building CXX object CMakeFiles/emp-tool.dir/emp-tool/emp-tool.cpp.o
[ 7%] Linking CXX shared library libemp-tool.so
[ 7%] Built target emp-tool
Scanning dependencies of target netio
[ 10%] Building CXX object CMakeFiles/netio.dir/test/netio.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/netio.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
In file included from /usr/include/string.h:494:0,
from /usr/include/c++/7/cstring:42,
from /home/locomotive/emp/emp-tool-master/emp-tool/utils/block.h:23,
from /home/locomotive/emp/emp-tool-master/emp-tool/io/io_channel.h:3,
from /home/locomotive/emp/emp-tool-master/emp-tool/io/file_io_channel.h:5,
from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:2,
from /home/locomotive/emp/emp-tool-master/test/netio.cpp:1:
In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘void emp::RecverSubChannel::recv_data(void*, int)’ at /home/locomotive/emp/emp-tool-master/emp-tool/io/highspeed_net_io_channel.h:97:10,
inlined from ‘void emp::HighSpeedNetIO::recv_data_internal(void*, int)’ at /home/locomotive/emp/emp-tool-master/emp-tool/io/highspeed_net_io_channel.h:247:22,
inlined from ‘void emp::IOChannel::recv_bool(bool*, int) [with T = emp::HighSpeedNetIO]’ at /home/locomotive/emp/emp-tool-master/emp-tool/io/io_channel.h:18:3:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:71: warning: ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
^
[ 14%] Linking CXX executable bin/netio
[ 14%] Built target netio
Scanning dependencies of target prp
[ 17%] Building CXX object CMakeFiles/prp.dir/test/prp.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/prp.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 21%] Linking CXX executable bin/prp
[ 21%] Built target prp
Scanning dependencies of target int
[ 25%] Building CXX object CMakeFiles/int.dir/test/int.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/int.cpp:2:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 28%] Linking CXX executable bin/int
[ 28%] Built target int
Scanning dependencies of target hash
[ 32%] Building CXX object CMakeFiles/hash.dir/test/hash.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/hash.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 35%] Linking CXX executable bin/hash
[ 35%] Built target hash
Scanning dependencies of target garble
[ 39%] Building CXX object CMakeFiles/garble.dir/test/garble.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/garble.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h: In constructor ‘emp::BristolFormat::BristolFormat(const char*)’:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:23:3: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "%d%d\n", &num_gate, &num_wire);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:24:3: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "%d%d%d\n", &n1, &n2, &n3);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:25:3: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "\n");
^~~~~~~~~~~~~~~~~~~~~
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:30:4: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "%d", &tmp);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:32:5: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "%d%d%d%d%s", &tmp, &gates[4i], &gates[4i+1], &gates[4i+2], str);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:37:5: warning: ignoring return value of ‘int fscanf(FILE, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
(void)fscanf(f, "%d%d%d%s", &tmp, &gates[4i], &gates[4i+2], str);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 42%] Linking CXX executable bin/garble
[ 42%] Built target garble
Scanning dependencies of target f2k
[ 46%] Building CXX object CMakeFiles/f2k.dir/test/f2k.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/f2k.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 50%] Linking CXX executable bin/f2k
[ 50%] Built target f2k
Scanning dependencies of target netio2
[ 53%] Building CXX object CMakeFiles/netio2.dir/test/netio2.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/netio2.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 57%] Linking CXX executable bin/netio2
[ 57%] Built target netio2
Scanning dependencies of target gen_circuit
[ 60%] Building CXX object CMakeFiles/gen_circuit.dir/test/gen_circuit.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/gen_circuit.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 64%] Linking CXX executable bin/gen_circuit
[ 64%] Built target gen_circuit
Scanning dependencies of target prg
[ 67%] Building CXX object CMakeFiles/prg.dir/test/prg.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/prg.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 71%] Linking CXX executable bin/prg
[ 71%] Built target prg
Scanning dependencies of target bit
[ 75%] Building CXX object CMakeFiles/bit.dir/test/bit.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/bit.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 78%] Linking CXX executable bin/bit
[ 78%] Built target bit
Scanning dependencies of target ecc
[ 82%] Building CXX object CMakeFiles/ecc.dir/test/ecc.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/ecc.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 85%] Linking CXX executable bin/ecc
[ 85%] Built target ecc
Scanning dependencies of target mitccrh
[ 89%] Building CXX object CMakeFiles/mitccrh.dir/test/mitccrh.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/mitccrh.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[ 92%] Linking CXX executable bin/mitccrh
[ 92%] Built target mitccrh
Scanning dependencies of target halfgate
[ 96%] Building CXX object CMakeFiles/halfgate.dir/test/halfgate.cpp.o
In file included from /home/locomotive/emp/emp-tool-master/emp-tool/emp-tool.h:10:0,
from /home/locomotive/emp/emp-tool-master/test/halfgate.cpp:1:
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:19:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
/home/locomotive/emp/emp-tool-master/emp-tool/circuits/circuit_file.h:68:14: warning: ignoring attributes on template argument ‘emp::block {aka __vector(2) long long int}’ [-Wignored-attributes]
vector wires;
^
[100%] Linking CXX executable bin/halfgate
[100%] Built target halfgate`

hi,
I'm trying to build the static library for iOS, before that I have a question, is it possible to build emp-toolkit for iOS which is running on arm64/armv7/armv7s architectures?

Thanks

clang: warning: argument unused during compilation: '-L/usr/local/Cellar/gmp/6.1.2/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-maes' [-Wunused-command-line-argument]
In file included from /Users/ned/Desktop/juzhenWorkingStation/6.MPC/ios-cmake-master/emp-tool-stable/test/com.cpp:1:
In file included from /Users/ned/Desktop/juzhenWorkingStation/6.MPC/ios-cmake-master/emp-tool-stable/utils/com.h:4:
In file included from /Users/ned/Desktop/juzhenWorkingStation/6.MPC/ios-cmake-master/emp-tool-stable/utils/hash.h:4:
In file included from /Users/ned/Desktop/juzhenWorkingStation/6.MPC/ios-cmake-master/emp-tool-stable/utils/block.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/xmmintrin.h:27:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:47:5: error: use of undeclared identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
__builtin_ia32_emms();
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:47:5: note: '__builtin_isless' declared here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:47:25: error: too few arguments to function call, expected 2, have 0
__builtin_ia32_emms();
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:64:19: error: use of undeclared identifier '__builtin_ia32_vec_init_v2si'
return (__m64)__builtin_ia32_vec_init_v2si(__i, 0);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:81:12: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2si'
return __builtin_ia32_vec_ext_v2si((__v2si)__m, 0);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:143:19: error: use of undeclared identifier '__builtin_ia32_packsswb'
return (__m64)__builtin_ia32_packsswb((__v4hi)__m1, (__v4hi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:173:19: error: use of undeclared identifier '__builtin_ia32_packssdw'
return (__m64)__builtin_ia32_packssdw((__v2si)__m1, (__v2si)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:203:19: error: use of undeclared identifier '__builtin_ia32_packuswb'
return (__m64)__builtin_ia32_packuswb((__v4hi)__m1, (__v4hi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:230:19: error: use of undeclared identifier '__builtin_ia32_punpckhbw'
return (__m64)__builtin_ia32_punpckhbw((__v8qi)__m1, (__v8qi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:253:19: error: use of undeclared identifier '__builtin_ia32_punpckhwd'
return (__m64)__builtin_ia32_punpckhwd((__v4hi)__m1, (__v4hi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:274:19: error: use of undeclared identifier '__builtin_ia32_punpckhdq'
return (__m64)__builtin_ia32_punpckhdq((__v2si)__m1, (__v2si)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:301:19: error: use of undeclared identifier '__builtin_ia32_punpcklbw'
return (__m64)__builtin_ia32_punpcklbw((__v8qi)__m1, (__v8qi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:324:19: error: use of undeclared identifier '__builtin_ia32_punpcklwd'
return (__m64)__builtin_ia32_punpcklwd((__v4hi)__m1, (__v4hi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:345:19: error: use of undeclared identifier '__builtin_ia32_punpckldq'
return (__m64)__builtin_ia32_punpckldq((__v2si)__m1, (__v2si)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:366:19: error: use of undeclared identifier '__builtin_ia32_paddb'; did you mean '__builtin_arm_qadd'?
return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:366:19: note: '__builtin_arm_qadd' declared here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:366:40: error: cannot initialize a parameter of type 'int' with an rvalue of type '__v8qi' (vector of 8 'char' values)
return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2);
^~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:387:19: error: use of undeclared identifier '__builtin_ia32_paddw'; did you mean '__builtin_arm_qadd'?
return (__m64)__builtin_ia32_paddw((__v4hi)__m1, (__v4hi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:366:19: note: '__builtin_arm_qadd' declared here
return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:387:40: error: cannot initialize a parameter of type 'int' with an rvalue of type '__v4hi' (vector of 4 'short' values)
return (__m64)__builtin_ia32_paddw((__v4hi)__m1, (__v4hi)__m2);
^~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:408:19: error: use of undeclared identifier '__builtin_ia32_paddd'; did you mean '__builtin_arm_qadd'?
return (__m64)__builtin_ia32_paddd((__v2si)__m1, (__v2si)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:366:19: note: '__builtin_arm_qadd' declared here
return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:408:40: error: cannot initialize a parameter of type 'int' with an rvalue of type '__v2si' (vector of 2 'int' values)
return (__m64)__builtin_ia32_paddd((__v2si)__m1, (__v2si)__m2);
^~~~~~~~~~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

Hi, I'm trying to port the NetIO code and I can't understand what this line does

I've tried to run two consoles with respect to ALICE and BOB, but they stuck after printing "NetIO".

This is related to the high overhead of CI.

It appears that certain tests in the repo are closer to a benchmark than a test.

A good example is here:

	for (long long length = 2; length <= 8192; length*=2) {
		long long times = 1024*1024*32/length;
		block * data = new block[length+1];
		char * data2 = (char *)data;
		auto start = clock_start();
		for (int i = 0; i < times; ++i) {
			prg.random_data(data2, length*16);
			//prg.random_data_unaligned(data2+1, length*16);
		}
		double interval = time_from(start);
		delete[] data;
		cout << "PRG speed with block size "<<length<<" :\t"<<(length*times*128)/(interval+0.0)*1e6*1e-9<<" Gbps\n";
	}

This is left as a future todo. It is also challenging to think about what tests would give us good coverage.

我想问一下为什么有test/float.cpp但是在bin/目录下没有float文件，这个float如何才能测试.

I am not sure if I am testing wrong, but could someone test Float a(24, 9, -3, ALICE) and Float b(24, 9, 1.0, BOB) addition? I alway get 0...

ERROR in eb_param_set() at /mnt/e/Downloads/relic/src/eb/relic_eb_param.c,343: invalid value passed as input.
CAUGHT in eb_param_set() at /mnt/e/Downloads/relic/src/eb/relic_eb_param.c,354.

I am using Relic 0.4.

What might be the issue here? Is this a relic version problem?

I recently want to run Circuit ORAM on EMP-AGMPC (ah, both come mostly from you), so the main challenge is to write prepare_deepest and so on.

In Obliv-C, writing prepare_deepest would be simpler due to obliv if, in which the CIL compiler would take care of making whatever inside the obliv_if oblivious (by automatically writing a dummy else case for padding).

This obliv if, however, is not available in emp-toolkit, yet it would be a super useful grammar sugar if there is one. It also seems hard to add under the C++ environment. Obliv-C has to leverage the CIL, which is a heavy primitive that starts to fail to catch up with the new C standard and might not be a solution in the long run.

Any thoughts to add something similar?

One potential idea:

• The following focuses on the plaintext protocol, which people use to generate circuits from emp programs.

• We can add two macros/functions obliv_if_start(cond) and obliv_if_end, which instructs the underlying execution engine that the values in the middle would be conditioned by a specific oblivious bit cond.

• The underlying execution engine keeps a list of all the modified values and conditions them (by an oblivious selection) during obliv_if_end.

This would require some changes to the plaintext protocol:

• Currently, the plaintext protocol's labels are directly the "wire numbers". This would make it difficult to do conditioning during obliv_if_end, which would add a number of AND/XOR gates and thus wires.

• To handle this, we could formulate two kinds of labels: symbolic labels and actual labels, for each oblivious bit, where the actual labels are wire numbers, but symbolic labels not necessarily are.

• The oblivious data structures (e.g., Float) store symbolic labels, which would be transited to the actual labels by the plaintext engine during the writeup of the circuit files.

• This would allow the engine to write additional gates silently while being transparent to the emp program writing system.

In addition, a related discussion:

The current circuit format is somehow inflexible. It requires all the output wires to be at the end. Many programs have been paying additional XOR gates to copy the values, which is inexpensive but unnecessary.

As a side note, the community may love a brand-new circuit format that provides great flexibility? Multiparty input & output? Parallel execution? Reactive computation? Nontrivially circuit file compression (like, for the loop, write something repeat xxx-xxx gates with an offset xxx in the file instead of a number of mostly "repeated" logic)?

I guess these circuits are from Nigel Smart.

New Bristol's SHA256 has 22573 AND gates.
Old Bristol's SHA256 has 90825 AND gates.

This is because the new Bristol circuit uses a result by Steven Goldfeder, who pointed out that the synthesizer is using an inefficient adder. The old Bristol circuit is not updated accordingly.

Maybe we should just remove the SHA256 circuit file for old Bristol in case someone uses it? Since now a developer can and should choose the new one.

The file float.h conflicts with the C standard lib.

When using

find_package(emp-tool REQUIRED)
include_directories(${EMP-TOOL_INCLUDE_DIRS})

in a CMakeLists.txt file, the folder /usr/local/include/emp-tool gets added to the list of include directories. Because of that the following C++ program does not compile for example:

#include <gmpxx.h>

int main() {
}

(you can check without cmake via g++ -I/usr/local/include/emp-tool program.cc.)

I think a solution might be to only add /usr/local/include to the list of include directories instead of /usr/local/include/emp-tool.

But this issue might also arise inside emp-tool if ever the C standard lib float.h is used.

__AES__ constant would be the best. But it is only for C program. Sadly, we don't have the same thing in cmake.

According to the Internet, it is still suggesting checking the cpuinfo,

for Linux,
cpuid | grep -i aes
for Mac,
sysctl -n machdep.cpu | grep -i aes

awk is not necessary. Just not empty (I mean "\n") is sufficient.

This note is left for future discussion on AES check.

Hello, Xiao Wang, how can I count the communication sizes between two parties? Is the emp-tool support this? Thanks!

我自己的总结：./bin/ferret 1 12345 logn & ./bin/ferret 2 12345 logn
适用于任何文件的运行，可以运行tool的也可以是ot，sh2pc的
我想知道这是什么原因

Hi, thanks for the great work.

After building successfully on OSX Catalina, I get a segfault in the ecc test:

benediamond@Benjamins-MBP emp-tool % ./bin/ecc   
zsh: segmentation fault  ./bin/ecc

after doing some digging, it looks like the bad line is the add_mod call:

    ic = ia.add_mod(ib, G.order, G.bn_ctx);

let me know if you'd like me to raise a PR. thanks.

I modify the example code in gen_circuit.cpp(https://github.com/emp-toolkit/emp-tool/blob/master/test/gen_circuit.cpp) to generate binary circuit file. But I don't understand it.

My program for generating circuit file is as following:

void ham(int n) {
   Integer a(n, 114, ALICE);
   Integer b(n, 81, BOB);
   Integer c = a^b;
   Integer d = c.hamming_weight();
   d.reveal<string>();
}
int main(int argc, char** argv) {
   setup_plain_prot(true, "sort.txt");
   ham(2);
   finalize_plain_prot ();
}

After run this pargam, it generates a file, named sort.txt.

Running command cat ./sort.txt, it shows as following:

5 9
2 2 2
                                                                                                                                                                                              
2 1 0 2 4 XOR
2 1 1 3 5 XOR
2 1 0 0 6 XOR
2 1 6 4 7 XOR
2 1 6 5 8 XOR

Could you explain it line by line?

Thanks in advance.

So what happens is: Amazon cloud does not support RDSEED.
An automatic detection in CMakeLists.txt to jump to the random device would be highly appreciated.

Should we use try_run?
https://cmake.org/cmake/help/v3.0/command/try_run.html

Express installation procedure is producing the following warning (fresh Ubuntu 17.10 install):

/home/emptester/emptoolkit/emp-tool/emp-tool/execution/plain_circ.h:104:10: warning: `res’ is used uninitialized in this function [-Wuninitialized]
    return res;
           ^~~

Suggested fix. Rewrite this function as follows:

uint64_t arr[2];
arr[0] = b ? S1 : S0;
arr[1] = this->gid;
gid++;
return *reinterpret_cast<block*>(arr);

For example, running sse_trans with nrows = 128 and ncols = 24. The following fix worked for me:

  // The remainder is a block of 8x(16n+8) bits (n may be 0).
  //  Do a PAIR of 8x8 blocks in each step:
  if ((ncols % 8 == 0 && ncols % 16 != 0) ||
      (nrows % 8 == 0 && nrows % 16 != 0)) {
    // The fancy optimizations in the else-branch don't work if the above if-condition
    // holds, so we use the simpler non-simd variant for that case.
    for (cc = 0; cc <= ncols - 16; cc += 16) {
      for (i = 0; i < 8; ++i) {
        tmp.b[i] = h = *(uint16_t const *)&INP(rr + i, cc);
        tmp.b[i + 8] = h >> 8;
      }
      for (i = 8; --i >= 0; tmp.x = _mm_slli_epi64(tmp.x, 1)) {
        OUT(rr, cc + i) = h = _mm_movemask_epi8(tmp.x);
        OUT(rr, cc + i + 8) = h >> 8;
      }
    }
  } else {
    for (cc = 0; cc <= ncols - 16; cc += 16) {
      vec = _mm_set_epi16(*(uint16_t const *)&INP(rr + 7, cc),
                          *(uint16_t const *)&INP(rr + 6, cc),
                          *(uint16_t const *)&INP(rr + 5, cc),
                          *(uint16_t const *)&INP(rr + 4, cc),
                          *(uint16_t const *)&INP(rr + 3, cc),
                          *(uint16_t const *)&INP(rr + 2, cc),
                          *(uint16_t const *)&INP(rr + 1, cc),
                          *(uint16_t const *)&INP(rr + 0, cc));
      for (i = 8; --i >= 0; vec = _mm_slli_epi64(vec, 1)) {
        OUT(rr, cc + i) = h = _mm_movemask_epi8(vec);
        OUT(rr, cc + i + 8) = h >> 8;
      }
    }
  }

The current network I/O component, NetIO, does not have end-to-end encryption of the circuits. There are two small problems:

1. An in-path attacker (not a party in the MPC) could tamper the circuits in some ways, such that, the final result does not pass the check, and the computation becomes futile. If there is TLS, the parties could detect that earlier and may not waste so much computation resource.
2. If in the future there are going to be honest-majority MPC tools in emp-toolkit, the honest-majority MPC platforms may need TLS connections among each other to prevent a network attacker from inferring additional information.

One who wants to implement TLS connections may add Secure Socket API (SSAPI, USENIX Security'18) or just add an OpenVPN between the parties. Yet, these implementations are kind of untidy and might not be the optimal option.

So, is there a plan to add TLSIO?

In addition, there might be an interesting research problem here. Nowadays, the fastest TLS cipher suite, I believe, is AES-GCM AEAD leveraging AES-NI. So, a pure implementation AG-MPC + TLSIO could end up to be 2x the calls to AES compared to no-TLS implementations. It would be interesting to see if one can avoid so many additional AES calls by designing an MPC protocol where adding network encryption & authentication is cheap, without the need for standard TLS.

When I cmake the project, I get this message:

-- Build type: Release
-- CXX Flags: -pthread -Wall -march=native -O3 -maes -mrdseed -std=c++11
-- Source of Randomness: random_device
-- GMP libs: /usr/lib/x86_64-linux-gnu/libgmp.so /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rean/Desktop/emp/emp-tool

I am confuse about the Source of Randomness: random_device is red color, why? Is something wrong with my device??But the compile works well.

When I configure the project,

there is a red sentence, will it affect the program?

Current master: 6ec9345

In emp-tool/circuits/integer.h, init has the following declaration:

57: void init(Bit * bits, const bool* b, int length, int party = PUBLIC);

In emp-tool/circuits/integer.hpp, there is this definition:

124: inline void init(vector<Bit>& bits, const bool* b, int length, int party)

The example showed in the README.md is incorrect: https://github.com/emp-toolkit/emp-tool#pseudorandom-permutation .

The wrong code is as following:

block key; PRG().random_block(&key,1); PRP prp(&key);

You can see the definition of PRP and it takes a const block& type as parameter.

PRP(const block& key)

Here, you give a pointer to const block type.

I think there is a memory leak in PRG::random_mpz: data is allocated via new but is not deleted. Furthermore, alignement is not ensured if I'm not mistaken. It might be better to allocate directly blocks of 16 bytes instead of bytes.

By the way, why do you add 16 bytes?

One error I encounter with Travis on emp-m2pc is that instruction not supported. I guess it is the random rdseed instruction problem (not sure now, try to confirm).

Now, if I run Travis on emp-m2pc, it also automatically git clone emp-tool, emp-m2pc should be compiled without rdseed. But now it still seems strange.

Any information for your experience in this?

What is the version of g++ shall I use? I have a compiling error when running the make file. Here is the capture.
(Seems the sha3_256 requires parameters but the code does not feed one).

d707eac removes double_block, which is used in ag2pc, thus breaking the setup in https://github.com/MPC-SoK/frameworks/.

The use of a raw pointer for the field rnd of the class PRG yields a memory leak on exit. I think it might be better to use std::unique_ptr.

In the class PRP, you have a pointer data member that the class owns (the class creates it in the constructor and destroys it in the destructor). In that setting, you should apply the rule of 3 or 5 (http://en.cppreference.com/w/cpp/language/rule_of_three). Currently the following program crashes because of that:

#include <prp.h>
#include <vector>
#include <string>

int main() {
  char key[16];
  std::vector<char> plain(16, 0);

  PRP prp;
  prp.aes_set_key(key);
  prp.permute_data(&plain[0], 16);

  PRP prp2 = prp;
  prp2.permute_data(&plain[0], 16);
}

The pointer prp.aes is deleted twice (once because of prp and once because of prp2).
In more complex examples, you can get segfaults.

I think there are 3 solutions:

1. do not use a pointer but directly an object: AES_KEY aes instead of AES_KEY *aes.
2. use a shared pointer shared_ptr
3. apply the rule of 5

I think the first solution makes the more sense in this case, but I have not checked the other parts of the code. They may rely on having a pointer.

If F(st, msg) is the compression function of SHA-2, we are computing F(0, 0). The expected output is 7ca51614425c3ba8ce54dd2fc2020ae7b6e574d198136d0fae7e26ccbf0be7a6 but the below circuit outputs 65E7D0FD33647E75F0B6C8198B2EA76DE7504043F4BB2A7315DC3A422868A53E

(Tested with the current master 53be447e972b8436b2c0a12e25c460d2665d869f)

#include "emp-tool/emp-tool.h"

// expected out: 7ca51614425c3ba8ce54dd2fc2020ae7b6e574d198136d0fae7e26ccbf0be7a6
void sha2_check() {
    emp::Integer inp(512 + 256, 0, emp::ALICE);

    emp::Integer out(256, 0, emp::PUBLIC);

    std::string filepath = "/usr/local/include/emp-tool/circuits/files/bristol_fashion/sha256.txt";
    emp::BristolFashion cf(filepath.c_str());
    cf.compute(out.bits.data(), inp.bits.data());
    std::cout << out.reveal<std::string>() << std::endl;
}

int main(int argc, char** argv) {
	emp::setup_plain_prot(false, "tmp.txt");
    sha2_check();
	emp::finalize_plain_prot();
}

We are using _pdep_u64 and _pext_u64 somewhere but not all. We should have unified interface for this conversion.

The functions PRP::aes_set_key and PRP::permute_data require 128-bit-aligned inputs. This is not really an issue but it might be good to add a comment.

For example, the following example will crash:

#include <prp.h>
#include <vector>
#include <string>

int main() {
  char key[16];
  std::vector<char> plain(17, 0);

  PRP prp;
  prp.aes_set_key(key);
  prp.permute_data(&plain[1], 16);
}

Using std::string to store binary data (this might arguably be a bad choice to do so, but some frameworks as GRPC do it) does not provide the required alignment on macOS, for example.

I am running the samples of emp::PRG shown in the README.md, but it displays that the prg.random_mpz is not found. After double checking the prg.h in emp-tool/utils, I think there is no member function called random_mpz in class PRG.

Any ideas on how to replace that function?

更新的工具安装报错

我发现在test文件夹下没有sha_256.cpp.o文件
不知道为什么

Hey all!

I'm currently trying to install this as dependency for Scapi.
However, I'm currently observing the following error:

In file included from emp-tool/io/io_channel.h:3:
emp-tool/utils/prg.h:149:14: error: use of undeclared identifier 'fmemopen'; did you mean 'freopen'?
                FILE *fp = fmemopen(data, nbytes+16, "rb");
                           ^~~~~~~~
                           freopen
/usr/include/stdio.h:248:7: note: 'freopen' declared here
FILE    *freopen(const char * __restrict, const char * __restrict,
         ^

and then

In file included from emp-tool/io/io_channel.h:3:
emp-tool/utils/prg.h:149:23: error: cannot initialize a parameter of type 'const char *' with an lvalue of
      type 'uint8_t *' (aka 'unsigned char *')
                FILE *fp = fmemopen(data, nbytes+16, "rb");
                                    ^~~~
/usr/include/stdio.h:248:38: note: passing argument to parameter here
FILE    *freopen(const char * __restrict, const char * __restrict,

A bit googling directed me to https://github.com/springlobby/lsl/blob/master/src/lslunitsync/image.cpp#L46 where they implement a custom fmemopen method.

However, I'm a bit unsure how to proceed to get this working.
Could you help me out?

Float circuits are not optimized.

On macOS, the compiler (llvm) calls std::bind instead of bind from sys/socket.h in io/net_io_channel.h (line 48).
There is no warning. But accept then hangs forever.

The solution is to replace bind by ::bind (or to not use using namespace std;).
See https://stackoverflow.com/questions/10035294/compiling-code-that-uses-socket-function-bind-with-libcxx-fails

Maybe, it would be interesting to also check the return code of bind and listen (in that case, you actually would get an error message when trying to compile without ::, as std::bind does not return an integer), e.g.:

if(::bind(mysocket, (struct sockaddr *)&serv, sizeof(struct sockaddr)) < 0) {
    perror("error: bind");
    exit(1);
}
if(listen(mysocket, 1) < 0) {
    perror("error: listen");
    exit(1);
}

I'm upgrading from emp-tool commit 508db17 to the latest version 0.2.2. When I tested it out in our codebase I noticed about a 15% increase in network traffic.

Chatting with Xiao it sounds like this may be due to an adhoc optimization that was in the original version of the code (here). That optimization could reduce the circuit size, but could also increase the runtime.

Could we add an option to enable that optimization again?

For some applications, it might be useful to support uint128_t and uint256_t. Do you plan to add such extensions?
Currently, the emp::Integer constructor works with inputs of type int64_t. Unless I'm missing something, I think all that would be needed is to include <boost/multiprecision/cpp_int.hpp> in circuits/integer.h and utils/utils.h, and add a specific constructor for each type. Or, is it the case that you wouldn't like to rely on Boost C++ libraries?

I am accessing EMP via an FFI, and I would like to be able to launch multiple sessions of EMP from one process. Unfortunately, since prot_exec and circ_exec are static, this won't work.

I think that if the circuits were modified to instead take as an argument the protocol / circuit execution then this would be possible.

For example:

1. Modify Bit::reveal (https://github.com/emp-toolkit/emp-tool/blob/master/emp-tool/circuits/bit.hpp#L22) to take a ProtocolExecution * as an additional argument. Call ->reveal on the argument.
2. When initializing semi-honest, return an object containing the protocol execution and circuit execution. Later calls to Bit::reveal etc. will then pass the ProtocolExecution that was returned from setting up the semihonest protocol.
   https://github.com/emp-toolkit/emp-sh2pc/blob/master/emp-sh2pc/semihonest.h#L12

Hope this makes sense. Let me know what you think!

编译的时候用了-ENABLE=on，报未定义引用错误，找半天错误没找到。

Is there a way to generate the circuits for hashing and commitment for performing them in mpc.
The gen_circuit code generates circuit files for functionality over emp::Integer and emp::Bit. But if I were to generate a circuit employing hashing and commitment in mpc over secret inputs in addition to other operations, is that possible? Or is there an alternative way to achieve this?

Hi, would it be possible to perform the offline phase of ag2pc and then marshall the state to disk. Then at some future time, the data can be unmarshalled to resume the online phase.

I looked around the emp-tool's code, I didn't find anything which suggests that it is possible. Now, I'm ok with implementing the marshalling myself, I just don't want to reinvent the wheel.
I'd be thankful if you could confirm whether such functionality already exists.