Implement fast pairing according to SFC specification

(This issue has been imported from the Gitlab repository because it seems to not have been addressed yet)

Original Text (Issue 70)

To get really fast pairings for various hardware architectures, the pbc Java implementation is not appropriate. This issue requests the integration of fast hardware specific pairings into the new interface. The arithmetic upto the pairing computation is provided as a library that is called from within java.

Comment by Jan Bobolz

New idea is to handle group operations, exponentiations, and pairings completely inside a C library (which [at]peterg writes). We ([at]mirkoj ?!) then write a Java (JNI) wrapper that calls the C library for group operations and exposes the Group/GroupElement interface.

The main advantage is that we only need to implement group operations once (namely, in C), and that we do not have to implement a semantic-preserving mapping of the C-representation of elliptiv curve points and their corresponding Java object hierarchy (which turns out to be a lot of code and which probably causes a lot of unnecessary runtime overhead). So the C code produces points as simple structs and just hands the bytes in the struct's allocated memory to Java. Java would only get to see"black box" bit strings. Java can then hand back that bit string, which the C code can directly interpret as the appropriate struct.

Comment by Peter Günther

The pairing that shall be implemented as part of this issue is the (optimal) ate pairing on BN curves. Details pending.

Comment by Peter Günther

issure is handled in branch feature/fast_pairing_sfc

Comment by Jan Bobolz

One of the tasks left here is to integrate it into the build process. I propose to make the native implementation (Java and C side) its own project so that people can build upb_pbc without any platform-dependent worries. (However, I'm not sure yet how to elegantly do the decision whether to instantiate the java or the native pairing.)

For future reference, I found

http://www.tricoder.net/blog/?p=197 which seems pretty clean.
https://www.humboldt.co.uk/wrapping-a-native-library-with-maven/ which may be more appropriate as Peter has already supplied a make file.

cryptimeleon / math