Convert AES-128-CTR to pre-parsed C++ circuit

[kdrag0n]

• Add support for loading and generating pre-parsed C++ code for BristolFashion circuits (mostly copied from BristolFormat)
• Use a pre-parsed AES-128 circuit for AES_128_CTR_Calculator in order to improve initialization time, especially in environments where sscanf is relatively slow (45 -> 35 ms in a program that uses the AES_128_CTR_Calculator)

[wangxiao1254]

Thanks for your contribution. However, I'm not sure if it is a good idea to put aes_128.cpp as the source since it is essentially duplicated information with aes_128.txt.

There is a pre-parsed AES from https://github.com/emp-toolkit/emp-tool/blob/master/CMakeLists.txt#L17 already. What's the difference?

[kdrag0n]

Thanks for your contribution. However, I'm not sure if it is a good idea to put aes_128.cpp as the source since it is essentially duplicated information with aes_128.txt.

I agree that the duplication isn't ideal, but I'm not sure what the alternative is. The txt.cpp file can be generated at compile-time with shell commands, but generating this is a bit more complicated and requires calling BristolFashion::to_file from C++.

There is a pre-parsed AES from https://github.com/emp-toolkit/emp-tool/blob/master/CMakeLists.txt#L17 already. What's the difference?

The txt.cpp + fmemopen approach is certainly faster than reading from a file, but in my testing, it's still considerably slower than this because the textual data is parsed with sscanf (character-by-character) every time AES_128_CTR_Calculator is initialized.

This pre-parsed circuit already has all the text parsed into numbers that are compiled into the library as constant data (similar to the output of BristolFormat::to_file) and offloads the cost of parsing to a one-time job, so the program never incurs the cost of sscanf. The cost can be significant in some slower environments.

Benchmarks of a program that uses AES_128_CTR_Calculator, before and after this change:

Host: 45 -> 35 ms
Slower environment: 350 -> 250 ms (mostly relevant here)

[wangxiao1254]

The aes_128.txt.cpp does not need fmemopen right? the array is compiled to a binary statically.

[kdrag0n]

The txt.cpp file looks like this:

#include "emp-tool/circuits/aes_128_ctr.h"
unsigned char emp_tool_circuits_files_bristol_fashion_aes_128_txt[] = {
  0x33, 0x36, 0x36, 0x36, 0x33, 0x20, 0x33, 0x36, 0x39, 0x31, 0x39, 0x0a,
  0x32, 0x20, 0x31, 0x32, 0x38, 0x20, 0x31, 0x32, 0x38, 0x20, 0x0a, 0x31,
  0x20, 0x31, 0x32, 0x38, 0x20, 0x0a, 0x0a, 0x32, 0x20, 0x31, 0x20, 0x31,
  0x32, 0x38, 0x20, 0x30, 0x20, 0x33, 0x33, 0x32, 0x35, 0x34, 0x20, 0x58,
  0x4f, 0x52, 0x0a, 0x32, 0x20, 0x31, 0x20, 0x31, 0x32, 0x39, 0x20, 0x31,
  0x20, 0x33, 0x33, 0x32, 0x35, 0x35, 0x20, 0x58, 0x4f, 0x52, 0x0a, 0x32,
  0x20, 0x31, 0x20, 0x31, 0x33, 0x30, 0x20, 0x32, 0x20, 0x33, 0x33, 0x32,
  0x35, 0x36, 0x20, 0x58, 0x4f, 0x52, 0x0a, 0x32, 0x20, 0x31, 0x20, 0x31,

It's compiled into the binary, but the embedded data is the content of aes_128.txt — still in textual form. fmemopen is used to open a virtual FILE pointing to this data so the text can be parsed with fscanf:

emp-tool/emp-tool/circuits/aes_128_ctr.h

Line 108 in f1f46ff

FILE * circuit_file = fmemopen(emp_tool_circuits_files_bristol_fashion_aes_128_txt,

emp-tool/emp-tool/circuits/circuit_file.h

Line 166 in 1345a14

(void)fscanf(f, "%d%d%d%d%s", &tmp, &gates[4*i], &gates[4*i+1], &gates[4*i+2], str);

[wangxiao1254]

I see you are right! I think the best way is to modify the existing code so that the generated array in the current code base does not need parsing anymore, right?