Implement SecureNN protocol about tf-encrypted

[koenvanderveen]

cool!

[mortendahl]

@snwagh sounds good -- and keep us posted for the C++ code!

[koenvanderveen]

wow, the field of mpc is really evolving. I think this would already be fast enough for some practical applications

[koenvanderveen]

Do you just want to recreate this implementation or also implement others?

[mortendahl]

Not sure I follow? The overall idea would be to support several protocols, including two-server SPDZ and SecureNN, and let users easily choose which protocol to use the same way they choose which ML model to use. Eventually find a way to add GC etc as well. There should be good defaults of course.

Something along these lines:

with tfe.protocol.TwoServerSPDZ(server1, server2, crypto_producer):
    with tfe.session() as sess:
        logreg = tfe.estimator.LogisticClassifier(
            session=sess,
            num_features=2,
        )

although still debating the form and order :)

[snwagh]

@mortendahl, @koenvanderveen I intend to open source the code soon.

[mortendahl]

that's great @snwagh! which language/platform did you use? interested in helping porting it to TensorFlow?

[snwagh]

The entire code is in C++.
Porting to TensorFlow sounds fun, though I might have too many commitments for a while. Keep me in the loop and I'll try to contribute however I can.

[mortendahl]

any updates on getting the source code out @snwagh?

[snwagh]

Hi @mortendahl, not yet, I was thinking more of three/four weeks time.

[bendecoste]

I think we are ready to go ahead and implement this. There was some prototyping done by @jvmancuso and myself. We should be able to OS that code pretty soon but the gist is that we have the protocol implemented in python with numpy.

The plan is to continue developing in secureNN.py as it is setup now, since secureNN is a superset of spdz this seems like a pretty natural decision. We used numpy and all of the functions are vectorized so the translation to TF should be fairly straight forward with a couple caveats:

• We may need new tensor types
  The rings used in secureNN do not directly translate to what we are doing via CRT, we will likely need to come up with new mods for each share of the CRT (cc @mortendahl)
  • We need new types for Z_2^64 as well as Z_2^64-1
• Figure out the smallest tensor type we can use for Z_p (probably int16 because values can temporarily go negative during some ops, so unsigned int8 wouldn't fit them)

It is possible that these caveats would just go away if we have int64 tensors. There was some work done in the TF repo that discovered this may be an artificial boundary that we can just turn off.

[mortendahl]

hi @snwagh, just a ping in case you're interested in following along: work on this is now happening in the securenn branch, primarily as a new protocol SecureNN deriving from Pond

[ianlivingstone]

This is a duplicate of #106, we should consider closing this up!