-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Obliv-C over encrypted communication? #82
Comments
I strongly prefer not to add yet another dependency on the Obliv-C build process, but the suggestion is still interesting. I'd recommend a standalone library that integrates in: you could have your own I don't see a whole lot of value to encrypting anything but the reveal functions, but the integrity properties can still be useful. After all, the whole point of MPC is to not reveal any inputs. Please make sure you note this point in your library, or else users may mistakenly assume GC itself is broken. To your other point about better constructions, yes, you can probably find a much easier way to sign garbled circuits, albeit less modular. Something like signing feed and reveal logics should probably do the trick, but I didn't think too hard about the proof. And even that would only work for semi-honest protocols. For simple GCs without any interactive inputs, you can probably just sign a hash of the entire protocol transcript from your side and send it off to the other side before a reveal but after end of computation. |
Thanks for the ideas. Great ideas! To sum up,
Let me talk a little bit about signing. I think directly signing the current feed and reveal steps may be insufficient, as follows:
So, some modifications to the current reveal steps will be necessary. However, I think we don't want to send, for example, the hashes of both labels for each wires, which will lead to an 80x blowup for revealing. |
When you say "malicious party", do you mean some man-in-the-middle, or the party whose signature I am actually expecting? Malicious bit flips by a MITM will always be detected. For the cases where the other legitimate party has turned malicious, yes, you certainly cannot use a semi-honest protocol. A lot of other things need to change for that. |
I mean man-in-the-middle. Where is the protection that "Malicious bit flips" will be detected? |
Take the string of all LSB bits sent during reveal, and sign it. The point of signing is that the other party can verify it with my pre-shared public key. |
What if the "bit flips" happen in the sending/receiving of garbled gates? I mean, one party already receives incorrect "half-gates". |
Yes, there are lots of such potential pitfalls, and such a protocol should never be trusted without proper proofs. |
If we don't just sign the LSB, but sign the hashes of two labels (the 0-label and 1-label), there is still an obstacle: Maybe a bit flip only makes a gate abnormal IN SOME CASES. For example, if a gate Thus, there needs a proof showing that "if there is a bit flip, both labels will be affected." And we need to show that "it is impossible that the affected wire will be later magically corrected in later gates if the attacker makes another bit label." |
The overkill solution is to sign everything, including OT and the circuit. So, I smell some academic research here... even in the malicious case, we don't want a network attacker to easily create chaos, right? |
The motivating example for malicious case (off-topic for Obliv-C): 10 companies are actually honest, but they run a maliciously secure 10-party federated learning platform. After THREE months of computation, they figured out that on the second day, a malicious attacker flipped one bit -- but they were previously unaware of that. The eventual result, after the three months, becomes totally useless. |
In case the two servers are over the Internet, the communication between them (i.e., OT, Yao's protocol) might need some sort of confidentiality and integrity protection.
Any thoughts about that? One potential idea is to apply Secure Socket API (SSA) (https://owntrust.org/ssa) onto the TCP protocol suite in
oblivc_bits.c
and add some additional socket flushing.Yet, think about that Yao's protocol is sending specific data, probably there is a better cryptographic construction for "encrypting/signing the GC".
The text was updated successfully, but these errors were encountered: