Plan to add TLSIO?

[weikengchen]

The current network I/O component, NetIO, does not have end-to-end encryption of the circuits. There are two small problems:

1. An in-path attacker (not a party in the MPC) could tamper the circuits in some ways, such that, the final result does not pass the check, and the computation becomes futile. If there is TLS, the parties could detect that earlier and may not waste so much computation resource.
2. If in the future there are going to be honest-majority MPC tools in emp-toolkit, the honest-majority MPC platforms may need TLS connections among each other to prevent a network attacker from inferring additional information.

One who wants to implement TLS connections may add Secure Socket API (SSAPI, USENIX Security'18) or just add an OpenVPN between the parties. Yet, these implementations are kind of untidy and might not be the optimal option.

So, is there a plan to add TLSIO?

In addition, there might be an interesting research problem here. Nowadays, the fastest TLS cipher suite, I believe, is AES-GCM AEAD leveraging AES-NI. So, a pure implementation AG-MPC + TLSIO could end up to be 2x the calls to AES compared to no-TLS implementations. It would be interesting to see if one can avoid so many additional AES calls by designing an MPC protocol where adding network encryption & authentication is cheap, without the need for standard TLS.

[wangxiao1254]

I myself am not planning for it since we do not need it for now. But pull request is welcome :)

[weikengchen]

I may contribute some code for this since it is needed for a project. My proposal for implementation is as follows. Let me know if there are any red flags.

IO channel

I think adding a separate IO channel for TLS (e.g., TLSIO) will be complicated, since a large part of emp-toolkit has been hard-coded with the string NetIO, e.g., NetIOMP, delta_ot.

So, a better solution might be to add a compiling option in emp-tool for enabling TLS connections in the NetIO channel. When this option is turned on, a TCP connection will become a TLS connection. Details of implementation are transparent to upstream tools. The TLS feature will be reserved for advanced players and be off by default.

Certificate

The standard method for establishing TLS connections is for servers to store each other's certificate. Other methods, like making PSK among each pair of parties, might not scale for AG-MPC. So it is a no-brainer to do certificates.

The NetIO will now check whether in the current directory, a subdirectory named certificates exists. If it exists, it loads the current party's certificates and private key and the CA certificate from that directory. Otherwise, it outputs a fatal error saying certificate not found. This check is only enabled when the compiling option asks to use TLS.

The IO channel checks the certificate based on whether the certificate's common name matches the IP address since NetIO does not have access to upstream information; that is, NetIO does not know the ID of the party connecting to.

Cipher

The TLS connection is likely implemented by TLS1.3 AES-GCM-128, AEAD. This should be so far the fastest method given AES-NI.

[wangxiao1254]

Great! I would prefer making NetIOMP, DeltaOT,... templated with IO rather than the other way around for long-term maintenance. If we can make it similar to ".ssh/authorized_keys". That might also be a good option. Ideally, this should be hooked with existing systems that manage public keys somehow. Xiao

…

On Fri, Jun 21, 2019 at 3:07 PM Weikeng Chen ***@***.***> wrote: I may contribute some code for this since it is needed for a project. My proposal for implementation is as follows. Let me know if there are any red flags. IO channel I think adding a separate IO channel for TLS (e.g., TLSIO) will be complicated, since a large part of emp-toolkit has been hard-coded with the string NetIO, e.g., NetIOMP, delta_ot. So, a better solution might be to add a compiling option in emp-tool for enabling TLS connections in the NetIO channel. When this option is turned on, a TCP connection will become a TLS connection. Details of implementation are transparent to upstream tools. The TLS feature will be reserved for advanced players and be off by default. Certificate The standard method for establishing TLS connections is for servers to store each other's certificate. Other methods, like making PSK among each pair of parties, might not scale for AG-MPC. So it is a no-brainer to do certificates. The NetIO will now check whether in the current directory, a subdirectory named certificates exists. If it exists, it loads certificates from that directory. Otherwise, it outputs a fatal error saying certificate not found. This check is only enabled when the compiling option asks to use TLS. The IO channel has to locate a certificate by IP address since NetIO does not have access to upstream information, that is, NetIO does not know the ID of the party connecting to. Cipher The TLS connection is likely implemented by TLS1.3 AES-GCM-128, AEAD. This should be so far the fastest method given AES-NI. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64?email_source=notifications&email_token=AARKGCSVWLIEQO65WSIHVMDP3URINA5CNFSM4HZEHCDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJKVSI#issuecomment-504539849>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARKGCU4FCZ24ZRWBVPB7X3P3URINANCNFSM4HZEHCDA> .