Produce JNI Binding for Cryptography Library

[jorabin]

Agreed on meeting of 2023-10-17 that @rsinha would produce Java binding via JNI.

[jorabin]

2023-10-25 Rohit is working on this. Not all that simple.

[jorabin]

Thanks for the JNI interface, which raises some thoughts, as follows.

1. Noting that the API is predicated on the current protobuf definition, we think it would be better if it was more general.

   1.1 The current protobuf definition may change, meaning that different versions of this api would be required.

   1.2 We agreed that, in principle, at least, protobuf wire format is one choice for the protocol, others are possible and it would be good to decouple the cryptography from the concrete syntax in use.

   1.3 Noting also that the interface requires an amendment to the current protobuf definition with the addition of
   message

   DeRecCryptoBridgeMessage {
     repeated CommittedDeRecShare shares = 1;
   }

2. In order to decouple from the protobuf serialization and to make it more natural for a Java programmer, we had in mind an interface that looks like this:

public interface ShamirInterfaces {


   interface SplitterFactory {
       /**
        * create a new Shamir splitter
        * @param random a random number generator
        * @param count the number of shares to produce
        * @param threshold the recombination threshold
        * @return a splitter
        */
       Splitter newSplitter(SecureRandom random, int count, int threshold);
   }


   interface Splitter {
       /**
        * Split a secret according to the parameters established
        * @param id a secret id
        * @param version a version
        * @param secret some bytes
        * @return a list of shares suitable for redistribution
        */
       List<byte[]> split(DeRecSecret.Id id, int version, byte[] secret);


       byte[] combine(DeRecSecret.Id id, int version, List<byte[]> shares);
   }
}

3. This also raises the question as to why the StoreShareRequestMessage looks like it does.

   Surely all the helper needs to know is what the Secret.Id is, what the version number is and what the share bytes are. It’s not clear what the helper is supposed to do with any of the other information that is made available and surely it would be better if it was not made available, or was opaque to the helper?

[rsinha]

The JNI implementation does not depend on the protobuf definition, and can be used even if the protobuf definitions evolve. We are using the protobuf here as a serialization method to communicate between the java land and rust land, as jni-rs does not seem to provide conveninent methods for passing structs back and forth (FWICT). So, we are using protobuf to encode API arguments and responses as byte arrays.

It just happens to be the case that the protobufs in StoreShareRequestMessage are sufficient for our purpose here, and we define a new DeRecCryptoBridgeMessage type to aggregate multiple CommittedDeRecShare messages to marshal over the JNI bridge -- this message type is not meant to be added to the protobufs definitions.

[rsinha]

The intent is that the CommittedDeRecShare object has all relevant fields. In java land, they can be used to construct relevant protobuf messages, or other serialization formats. You can certainly define your proposed SplitterFactory interface on top of the jni interface here.

[jorabin]

In response:

1. Serialising and deserialising seems like quite an overhead
2. yes, one could implement that, but who is the "one" involved? Maintenance of the library and its interfaces should live in the same place.
3. It also doesn't address the point that all the additional information in the CommitedDeRecShare should not be available to a helper, but I suppose reasonable to argue that point should move to the protobuf repo?

[rsinha]

I think (de) serialization is a small fraction of the total compute cost, which includes polynomial arithmetic and SHA computations. Moreover, these operations are happening on sharer side (not helper), and presumably not that often, right?

[jorabin]

For clarity, I think the scope of this work should include a) test suite (including performance), b) some kind of implementation agnostic interface such as that proposed above, c) a versioned JAR containing binaries for common deployment options, d) usage examples.

[jorabin]

Closing this issue as partly addressed by PR #7 and new issues #8 and #9 to deal with other outstanding.