What language is better for implementing a private function evaluation protocol?

Question

I want to implement the 2-party PFE protocol of Katz and Malka (from their Asiacrypt 2011 paper: https://eprint.iacr.org/2010/528). I wanted to ask if there is a strong reason for me to choose one of the following languages for this task:

1. C or C++: I know these languages quite well and have been using them to implement algorithms for a while.

2. Go: I am also familiar with it, and personally like it slightly better than C++.

I am intentionally leaving out Python, as I want to work on this project for a long time and don't think Python would be a good choice for this kind of project. The KM'11 PFE protocol is the first protocol I need to implement, but most probably not the last one. My implementations will be part of a research project.

A strong reason would be how efficient, "correct" (i.e. bug-free) and well-maintained the crypto libraries designed for these languages are, or how much they differ in the amount of implementation effort.

I would appreciate any pointers to learning resources or similar questions as well.

Answer 1

Go for Go.

Whilst perhaps not a pure cryptography question, it lies on the periphery.

Programming errors (specifically related to memory access) in C/C++ code account for the majority of the vulnerabilities in large code bases. Heard of that CloudStrike thing? That was illegal memory access within the kernel space. What do you need pointer arithmetic for anyway?

Many organisations and national security agencies are now recommending that C/C++ is deprecated for new projects. If Rust (now in the Linux kernel) doesn't suite you, you're left with Go and its memory safety.

Answer 2

Criteria that influence the library or libraries of choice, and often, thru that, the language.

1. On top of what (singly) homomorphic encryption you want to implement this protocol (that's discussed at start of section 2.2), and if you want the library to implement that or are ready to write it. Reasonable choices, from simpler to more complex:
   • ElGamal in the multiplicative group modulo a safe prime, but the group order is even thus not prime and the consequences in the context are not immediately clear to me.
   • ElGamal in the subgroup of quadratic residues of the above group. Now this is of prime order.
   • Paillier: slower addition but faster scalar multiplication, which possibly is used in the part that reads $\mathsf{Enc}_{pk}(am+b)$. Different security properties (in particular knowing $\underbrace{m\dot+m\dot+\dots\dot+m}_{a\text{ terms}}$ and $m$ a known element of the paintext group with law $\dot+$, it's easy to find $a$ modulo the group order, when that's assumed hard for ElGamal's plaintext group. I don't see this discussed, and it's not immediately clear to me if that's a concern for the protocol at hand.
   • ElGamal on an Elliptic Curve group of prime order (faster, more compact cryptograms).
2. Target Operating System, CPU(s), compiler. Not everything is (name an OS) running on (name a CPU) with (name a compiler), and many if not most crypto-oriented libraries are a hell to port across these, because of the next two points.
3. How much you want an implementation that resists side-channel attacks, or the timing-and-cache-related side-channel attacks subset of that. If you deeply care, that rules out many libraries (and some languages for these, including most interpreted languages). E.g. Go's math.big is a no-go, at least absent countermeasures. Same for java.math.BigInteger and arguably anything on top of that, even compiled.
4. Need for speed. Differences between libraries can be tremendous.
5. License model(s) that fit you.

It's not indispensable that the library is written for the language you'll use. Often it's possible to use a binding, especially for a library in C. E.g. GMP, which is C and assembly with a C++ optional icing, seems usable from Go with this or that binding (however GMP has limited support for timing-and-cache-related side-channel resistance).

While it's true that Go or Rust won't let you inadvertently shoot yourself in the foot with things like out-of-bound indexes or double-free, that's no longer sure when you use a binding to other code. And these languages may make it harder to write side-channel resistant code.

Answer 3

To implement the private function evaluation protocol, Python and Rust are the best choices: Python offers ease of use and libraries, while Rust offers performance and security to ensure efficient and safe execution.